incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <daniel.s.conne...@comcast.net>
Subject Re: Need to troubleshoot: open_error,-10
Date Tue, 22 Jul 2008 11:57:33 GMT
Dan Reverri wrote:
> Are you running couchdb as a different user? If so, have you set the
> LD_LIBRARY_PATH for this user correctly?
Hi Dan,

What does "correctly" mean?

Okay, so I am a "different user."   That is, I did not create a couchdb
user.   I did need to change permissions on 2 couchdb directories to
allow group "dev" to write there.   The different user is in group "dev".  

One possible source of my problem is that my architecture is x86_64 but
the OS is 32-bit.  But the architecture is hidden from the build system
and all the objects for Erlang and SpiderMonkey are 32-bit.

The ErrorMessages page (wiki) tells me to run couchdb this way:

    LD_LIBRARY_PATH=/usr/local/lib:/usr/local/js/lib couchd
      

THIS NEEDS MORE EXPLANATION IN THE WIKI.  In my case, "/usr/local/lib"
is useless.  What is its intended purpose?    The SpiderMonkey set-up is
clear, though.

dan32@Sun:~> ls -l /usr/local/js/lib
total 5156
-rw-r--r-- 1 root root 2748756 2008-07-21 10:08 libjs.a
-rwxr-xr-x 1 root root 2516756 2008-07-21 10:08 libjs.so

dan32@Sun:~> ls -l /usr/local/lib
total 8
drwxr-xr-x 4 root root 4096 2008-07-21 10:24 couchdb
drwxr-xr-x 8 root root 4096 2008-07-20 20:12 erlang

It should not be necessary to pre-set the LD_LIBRARY_PATH for the ICU
shared objects.   The couchdb script uses "icu-config" to put those
shared objects on the LD_LIBRARY_PATH dynamically, within the
invocation.     Such a dynamic set-up should be just fine for ICU.

In my case, OpenSuSE comes with ICU already installed into /lusr/lib,
not /usr/local/lib.      What are the shared objects you are expecting
in /usr/local/lib???

dan32@Sun:~> icu-config --invoke
env 'LD_LIBRARY_PATH=/usr/lib:${LD_LIBRARY_PATH}'

dan32@Sun:~> ls -l /usr/lib | grep icu
lrwxrwxrwx   1 root root       18 2008-07-20 19:05 libicudata.so ->
libicudata.so.36.0
lrwxrwxrwx   1 root root       18 2008-04-19 09:44 libicudata.so.36 ->
libicudata.so.36.0
-rwxr-xr-x   1 root root 10154796 2008-02-14 06:15 libicudata.so.36.0
lrwxrwxrwx   1 root root       18 2008-07-20 19:05 libicui18n.so ->
libicui18n.so.36.0
lrwxrwxrwx   1 root root       18 2008-04-19 09:44 libicui18n.so.36 ->
libicui18n.so.36.0
-rwxr-xr-x   1 root root  1329472 2008-02-14 06:15 libicui18n.so.36.0
lrwxrwxrwx   1 root root       16 2008-07-20 19:05 libicuio.so ->
libicuio.so.36.0
lrwxrwxrwx   1 root root       16 2008-04-19 09:44 libicuio.so.36 ->
libicuio.so.36.0
-rwxr-xr-x   1 root root    43308 2008-02-14 06:15 libicuio.so.36.0
lrwxrwxrwx   1 root root       16 2008-07-20 19:05 libicule.so ->
libicule.so.36.0
lrwxrwxrwx   1 root root       16 2008-04-19 09:44 libicule.so.36 ->
libicule.so.36.0
-rwxr-xr-x   1 root root   267128 2008-02-14 06:15 libicule.so.36.0
lrwxrwxrwx   1 root root       16 2008-07-20 19:05 libiculx.so ->
libiculx.so.36.0
lrwxrwxrwx   1 root root       16 2008-04-19 09:44 libiculx.so.36 ->
libiculx.so.36.0
-rwxr-xr-x   1 root root    38840 2008-02-14 06:15 libiculx.so.36.0
lrwxrwxrwx   1 root root       16 2008-07-20 19:05 libicutu.so ->
libicutu.so.36.0
lrwxrwxrwx   1 root root       16 2008-04-19 09:44 libicutu.so.36 ->
libicutu.so.36.0
-rwxr-xr-x   1 root root   109248 2008-02-14 06:15 libicutu.so.36.0
lrwxrwxrwx   1 root root       16 2008-07-20 19:05 libicuuc.so ->
libicuuc.so.36.0
lrwxrwxrwx   1 root root       16 2008-04-19 09:44 libicuuc.so.36 ->
libicuuc.so.36.0
-rwxr-xr-x   1 root root  1176976 2008-02-14 06:15 libicuuc.so.36.0

I guess I need to unravel this to the point where I can use "ldd" to
list the dependencies.    You would think that such a tool would be part
of the package.

       -- Dan Connelly


Dan Reverri wrote:
> Are you running couchdb as a different user? If so, have you set the
> LD_LIBRARY_PATH for this user correctly?
>
> On Mon, Jul 21, 2008 at 6:43 PM, Dan Connelly <daniel.s.connelly@comcast.net>
> wrote:
>
>   
>> <snip>
>>
>> Isn't this sufficient on LD_LIBRARY?   How can I force a verbose
>> dependency check?
>>
>>    -- Dan Connelly (not yet relaxed)
>>
>>     
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message