can't infer base LD_LIBRARY_PATH. Aborting.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

can't infer base LD_LIBRARY_PATH. Aborting.

Philippe Marschall-2-3
Hi

With the latest cog VMs I get:

can't infer base LD_LIBRARY_PATH. Aborting.

Gentoo 64bit, Linux 3.1

LD_LIBRARY_PATH is not set but libtool is present.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Eliot Miranda-2
Hi Phillipe,

    what does ldd answer for the squeak vm?  The script is trying to work out what default LD_LIBRARY_PATH to supply.  The choice is between /lib/tls:/lib:/usr/lib/tls:/usr/lib and /lib:/usr/lib.  Older linuxes had two versions of the pthreads library, an experimental one (now the default) using thread-local storage (hence tls) and an older one, I think using the stack pointer to identify the current thread.  The script uses ldd to find out what the VM is linked against.  Here's the code:

# On some old linuxes there is a /lib/tls thread-local-storage version of the C
# library which the VM may use and if so should take precedence over /lib libc.
case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)             SVMLLP="/lib:/usr/lib";;
*)                              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                                exit 1
esac

On Tue, Dec 27, 2011 at 9:51 AM, Philippe Marschall <[hidden email]> wrote:
Hi

With the latest cog VMs I get:

can't infer base LD_LIBRARY_PATH. Aborting.

Gentoo 64bit, Linux 3.1

LD_LIBRARY_PATH is not set but libtool is present.

Cheers
Philippe





--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Schwab,Wilhelm K
Eliot,

I apologize if this is retreaded ground.  I am still using an older, hacked, vm for most of my work.  The hacks provided diagnostic information in two ares:

(1) can't load an external library?  Then it helps to see the full path that was used; at least once, it ended up having an extra slash appended somewhere; various other times, I had not registered something correctly, and the mistake was obvious as soon as I saw what the vm was ultimately trying to load;

(2) Can't open a serial port?  Then it helps to see how the vm mapped it too.  I wish I remembered more of the details on this type of problem.  At least some of the trouble I have had is due to the realities of newer hardware forcing me to use USB to serial converters, which I find to be unreliable.  I am still sorting through the combination of Linux and some excellent hardware that I have used for years.

The short version is that when a library can't load or a port can't open, etc., and the vm did some translation of a name to a number (or vice versa), or manipulated a string, it would be nice to have syslog()/OutputDebugString() output to show what the vm tried to do.

Bill





From: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
Sent: Tuesday, December 27, 2011 1:18 PM
To: [hidden email]
Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

Hi Phillipe,

    what does ldd answer for the squeak vm?  The script is trying to work out what default LD_LIBRARY_PATH to supply.  The choice is between /lib/tls:/lib:/usr/lib/tls:/usr/lib and /lib:/usr/lib.  Older linuxes had two versions of the pthreads library, an experimental one (now the default) using thread-local storage (hence tls) and an older one, I think using the stack pointer to identify the current thread.  The script uses ldd to find out what the VM is linked against.  Here's the code:

# On some old linuxes there is a /lib/tls thread-local-storage version of the C
# library which the VM may use and if so should take precedence over /lib libc.
case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)             SVMLLP="/lib:/usr/lib";;
*)                              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                                exit 1
esac

On Tue, Dec 27, 2011 at 9:51 AM, Philippe Marschall <[hidden email]> wrote:
Hi

With the latest cog VMs I get:

can't infer base LD_LIBRARY_PATH. Aborting.

Gentoo 64bit, Linux 3.1

LD_LIBRARY_PATH is not set but libtool is present.

Cheers
Philippe





--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 27.12.2011 19:18, Eliot Miranda wrote:
> Hi Phillipe,
>
>      what does ldd answer for the squeak vm?

$ldd coglinux/lib/squeak/4.0-2515/squeak
        linux-gate.so.1 =>  (0xffffe000)
        libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
        libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
        libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
        libm.so.6 => /lib32/libm.so.6 (0xf7687000)
        libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
        libc.so.6 => /lib32/libc.so.6 (0xf750c000)
        /lib/ld-linux.so.2 (0xf76fe000)

It's a 64bit system with 32bit compatibility libraries (only for cog,
everything else is 64bit).

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Eliot Miranda-2
Hi Phillipe,

On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <[hidden email]> wrote:
On 27.12.2011 19:18, Eliot Miranda wrote:
Hi Phillipe,

    what does ldd answer for the squeak vm?

$ldd coglinux/lib/squeak/4.0-2515/squeak
       linux-gate.so.1 =>  (0xffffe000)
       libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
       libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
       libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
       libm.so.6 => /lib32/libm.so.6 (0xf7687000)
       libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
       libc.so.6 => /lib32/libc.so.6 (0xf750c000)
       /lib/ld-linux.so.2 (0xf76fe000)

It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit).

Ah, ok.  Makes sense.  So I expect the relevant code needs to read

# On some old linuxes there is a /lib/tls thread-local-storage version of the C
# library which the VM may use and if so should take precedence over /lib libc.
case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)     SVMLLP="/lib:/usr/lib";;
/lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
*)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                exit 1
esac

Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib?



Cheers
Philippe





--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Eliot Miranda-2
and is there a /lib32/tls?  (I hope not).  Does anyone have a linux system with either of the following?
    /lib32/tls
    /lib64/tls

TIA
Eliot

On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <[hidden email]> wrote:
Hi Phillipe,

On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <[hidden email]> wrote:
On 27.12.2011 19:18, Eliot Miranda wrote:
Hi Phillipe,

    what does ldd answer for the squeak vm?

$ldd coglinux/lib/squeak/4.0-2515/squeak
       linux-gate.so.1 =>  (0xffffe000)
       libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
       libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
       libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
       libm.so.6 => /lib32/libm.so.6 (0xf7687000)
       libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
       libc.so.6 => /lib32/libc.so.6 (0xf750c000)
       /lib/ld-linux.so.2 (0xf76fe000)

It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit).

Ah, ok.  Makes sense.  So I expect the relevant code needs to read

# On some old linuxes there is a /lib/tls thread-local-storage version of the C
# library which the VM may use and if so should take precedence over /lib libc.
case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)     SVMLLP="/lib:/usr/lib";;
/lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
*)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                exit 1
esac

Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib?



Cheers
Philippe





--
best,
Eliot




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Schwab,Wilhelm K
FWIW, I see neither on Ubuntu lucid, 32 bit.  There is not even a /lib32.

Bill




From: [hidden email] [[hidden email]] on behalf of Eliot Miranda [[hidden email]]
Sent: Tuesday, December 27, 2011 4:40 PM
To: [hidden email]
Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

and is there a /lib32/tls?  (I hope not).  Does anyone have a linux system with either of the following?
    /lib32/tls
    /lib64/tls

TIA
Eliot

On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <[hidden email]> wrote:
Hi Phillipe,

On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <[hidden email]> wrote:
On 27.12.2011 19:18, Eliot Miranda wrote:
Hi Phillipe,

    what does ldd answer for the squeak vm?

$ldd coglinux/lib/squeak/4.0-2515/squeak
       linux-gate.so.1 =>  (0xffffe000)
       libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
       libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
       libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
       libm.so.6 => /lib32/libm.so.6 (0xf7687000)
       libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
       libc.so.6 => /lib32/libc.so.6 (0xf750c000)
       /lib/ld-linux.so.2 (0xf76fe000)

It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit).

Ah, ok.  Makes sense.  So I expect the relevant code needs to read

# On some old linuxes there is a /lib/tls thread-local-storage version of the C
# library which the VM may use and if so should take precedence over /lib libc.
case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)     SVMLLP="/lib:/usr/lib";;
/lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
*)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                exit 1
esac

Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib?



Cheers
Philippe





--
best,
Eliot




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 27.12.2011 22:39, Eliot Miranda wrote:

> Hi Phillipe,
>
> On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 27.12.2011 19:18, Eliot Miranda wrote:
>
>         Hi Phillipe,
>
>              what does ldd answer for the squeak vm?
>
>
>     $ldd coglinux/lib/squeak/4.0-2515/__squeak
>             linux-gate.so.1 =>  (0xffffe000)
>             libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
>             libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
>             libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
>             libm.so.6 => /lib32/libm.so.6 (0xf7687000)
>             libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
>             libc.so.6 => /lib32/libc.so.6 (0xf750c000)
>             /lib/ld-linux.so.2 (0xf76fe000)
>
>     It's a 64bit system with 32bit compatibility libraries (only for
>     cog, everything else is 64bit).
>
>
> Ah, ok.  Makes sense.  So I expect the relevant code needs to read
>
> # On some old linuxes there is a /lib/tls thread-local-storage version
> of the C
> # library which the VM may use and if so should take precedence over
> /lib libc.
> case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
> /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
> /lib/libc*)     SVMLLP="/lib:/usr/lib";;
> /lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
> *)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
>                  exit 1
> esac
>
> Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of
> /usr/lib?
Yes there is. Not for the whole /usr/lib, but only the 32bit
compatibility libraries. Which was enough to run Squeak so far. Contents
attached.

Cheers
Philippe

usr_lib_32.txt (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

ngarbezza
In reply to this post by Eliot Miranda-2
On 27 December 2011 18:39, Eliot Miranda <[hidden email]> wrote:

> Hi Phillipe,
>
> On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <[hidden email]> wrote:
>>
>> On 27.12.2011 19:18, Eliot Miranda wrote:
>>>
>>> Hi Phillipe,
>>>
>>>     what does ldd answer for the squeak vm?
>>
>>
>> $ldd coglinux/lib/squeak/4.0-2515/squeak
>>        linux-gate.so.1 =>  (0xffffe000)
>>        libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
>>        libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
>>        libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
>>        libm.so.6 => /lib32/libm.so.6 (0xf7687000)
>>        libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
>>        libc.so.6 => /lib32/libc.so.6 (0xf750c000)
>>        /lib/ld-linux.so.2 (0xf76fe000)
>>
>> It's a 64bit system with 32bit compatibility libraries (only for cog,
>> everything else is 64bit).
>
>
> Ah, ok.  Makes sense.  So I expect the relevant code needs to read
>
> # On some old linuxes there is a /lib/tls thread-local-storage version of
> the C
> # library which the VM may use and if so should take precedence over /lib
> libc.
> case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
> /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
> /lib/libc*)     SVMLLP="/lib:/usr/lib";;
> /lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
> *)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
>                 exit 1
> esac
>
> Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of
> /usr/lib?
>
>

Hi,

I had the same error on Ubuntu 11.10 (32bit). This is the output from ldd:

$ ldd lib/squeak/4.0-2522/squeak
        linux-gate.so.1 =>  (0x00f42000)
        libutil.so.1 => /lib/i386-linux-gnu/libutil.so.1 (0x0066e000)
        libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00cfc000)
        libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x004af000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005b6000)
        libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0x00b03000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x00bf3000)

So I had to modify the squeak launcher in order to get it working:

case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*) SVMLLP="/lib:/usr/lib";;
/lib/i386-linux-gnu/libc*) SVMLLP="/lib/i386-linux-gnu";;
*) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                                exit 1

Cheers,
Nahuel.

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Eliot Miranda-2
Hi Nahuel,

On Thu, Jan 19, 2012 at 8:52 AM, Nahuel Garbezza <[hidden email]> wrote:
On 27 December 2011 18:39, Eliot Miranda <[hidden email]> wrote:
> Hi Phillipe,
>
> On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <[hidden email]> wrote:
>>
>> On 27.12.2011 19:18, Eliot Miranda wrote:
>>>
>>> Hi Phillipe,
>>>
>>>     what does ldd answer for the squeak vm?
>>
>>
>> $ldd coglinux/lib/squeak/4.0-2515/squeak
>>        linux-gate.so.1 =>  (0xffffe000)
>>        libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000)
>>        libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000)
>>        libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000)
>>        libm.so.6 => /lib32/libm.so.6 (0xf7687000)
>>        libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000)
>>        libc.so.6 => /lib32/libc.so.6 (0xf750c000)
>>        /lib/ld-linux.so.2 (0xf76fe000)
>>
>> It's a 64bit system with 32bit compatibility libraries (only for cog,
>> everything else is 64bit).
>
>
> Ah, ok.  Makes sense.  So I expect the relevant code needs to read
>
> # On some old linuxes there is a /lib/tls thread-local-storage version of
> the C
> # library which the VM may use and if so should take precedence over /lib
> libc.
> case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
> /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
> /lib/libc*)     SVMLLP="/lib:/usr/lib";;
> /lib32/libc*)   SVMLLP="/lib32:/usr/lib32";;
> *)              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
>                 exit 1
> esac
>
> Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of
> /usr/lib?
>
>

Hi,

I had the same error on Ubuntu 11.10 (32bit). This is the output from ldd:

$ ldd lib/squeak/4.0-2522/squeak
       linux-gate.so.1 =>  (0x00f42000)
       libutil.so.1 => /lib/i386-linux-gnu/libutil.so.1 (0x0066e000)
       libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00cfc000)
       libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x004af000)
       libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x005b6000)
       libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0x00b03000)
       libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
       /lib/ld-linux.so.2 (0x00bf3000)

So I had to modify the squeak launcher in order to get it working:

case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in
/lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";;
/lib/libc*)             SVMLLP="/lib:/usr/lib";;
/lib/i386-linux-gnu/libc*)              SVMLLP="/lib/i386-linux-gnu";;
*)                              echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2;
                               exit 1

Thanks.  But what's the corresponding /usr/lib?  e.g. is there a /usr/lib/i386-linux-gnu?  In this context LD_LIBRARY_PATH needs to contain a /lib and a /usr/lib.


Cheers,
Nahuel.




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

ngarbezza
> Thanks.  But what's the corresponding /usr/lib?  e.g. is there a
> /usr/lib/i386-linux-gnu?  In this context LD_LIBRARY_PATH needs to contain a
> /lib and a /usr/lib.
>

Yes, /usr/lib/i386-linux-gnu/ exists. As it worked, I thought it was
not necessary.

Nahuel

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

Eliot Miranda-2


On Thu, Jan 19, 2012 at 9:17 AM, Nahuel Garbezza <[hidden email]> wrote:
> Thanks.  But what's the corresponding /usr/lib?  e.g. is there a
> /usr/lib/i386-linux-gnu?  In this context LD_LIBRARY_PATH needs to contain a
> /lib and a /usr/lib.
>

Yes, /usr/lib/i386-linux-gnu/ exists. As it worked, I thought it was
not necessary.

The point is that LD_LIBRARY_PATH is used by dlopen, which is used by the VM's module loading mechanisms, etc, so that when e.g. the FFI tries to locate a library it will use LD_LIBRARY_PATH.  So a) LD_LIBRARY_PATH needs to match the libraries the VM is linked against and b) LD_LIBRARY_PATH needs to include at least the standard places libraries will be found, which means a /lib and a /usr/lib. 

HTH
Eliot


Nahuel




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: can't infer base LD_LIBRARY_PATH. Aborting.

mkobetic
In reply to this post by Philippe Marschall-2-3
Most probably know this, but just in case, recent versions of Linux distributions provide a more modular way to control the library path via the /etc/ld.so.conf.d/ directory.
For example I normally add path to oracle libraries by adding a file /etc/ld.so.conf.d/oracle-11.1-x86_64.conf with just a single line in it containing /usr/lib/oracle/11.1/client64/lib. I think you need to run ldconfig every time you modify the directory, but after that the library should be visible to all programs. You can add both 32 and 64 bit libraries this way. Not sure if this is immediately useful to help with this problem, but there it is.

HTH,

Martin

"Eliot Miranda"<[hidden email]> wrote:

> The point is that LD_LIBRARY_PATH is used by dlopen, which is used by the
> VM's module loading mechanisms, etc, so that when e.g. the FFI tries to
> locate a library it will use LD_LIBRARY_PATH.  So a) LD_LIBRARY_PATH needs
> to match the libraries the VM is linked against and b) LD_LIBRARY_PATH
> needs to include at least the standard places libraries will be found,
> which means a /lib and a /usr/lib.
>
> HTH
> Eliot
>
>
> > Nahuel
> >
> >
>
>
> --
> best,
> Eliot