setting LD_LIBRARY_PATH doesn't seem to work? 
Author Message
 setting LD_LIBRARY_PATH doesn't seem to work?

On a linux system, I've developed a extension to STAF (see previous
posts) that links to libSTAF.so to provide various bits of
functionality.  However, I had forgotten that I'd set my
LD_LIBRARY_PATH to find said library, so it was always loaded
correctly.

I discovered that it wasn't loading correctly when I ran some CGI code
I'd written around that extension.  So I did what I do in every other
programming language, and set ENV['LD_LIBRARY_PATH'] to point to
/usr/local/staf/lib, where the library resides.  Alas, this did not
work.  In fact, if I unset LD_LIBRARY_PATH in my environment and tried
this, it didn't work there either.

I'd suspect myself before I'd suspect ruby, but in this case, I think
I've covered all my bases.  Comments are welcome.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
                -- Blair Houghton



Sat, 30 Apr 2005 11:01:24 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

Quote:
> On a linux system, I've developed a extension to STAF (see previous
> posts) that links to libSTAF.so to provide various bits of
> functionality.  However, I had forgotten that I'd set my
> LD_LIBRARY_PATH to find said library, so it was always loaded
> correctly.

> I discovered that it wasn't loading correctly when I ran some CGI code
> I'd written around that extension.  So I did what I do in every other
> programming language, and set ENV['LD_LIBRARY_PATH'] to point to
> /usr/local/staf/lib, where the library resides.  Alas, this did not
> work.  In fact, if I unset LD_LIBRARY_PATH in my environment and tried
> this, it didn't work there either.

> I'd suspect myself before I'd suspect ruby, but in this case, I think
> I've covered all my bases.  Comments are welcome.

why not compile the module using LD_RUN_PATH?  relying on LD_LIBRARY_PATH is
evil ;-)

-a

--

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328

 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================



Sat, 30 Apr 2005 13:01:34 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

Quote:
> why not compile the module using LD_RUN_PATH?  relying on
> LD_LIBRARY_PATH is
> evil ;-)

I've heard this charge levied before; can someone tell me the
inherent evil in it?

I'm not doubting anyone, just curious.

=====
--

Yahoo IM: michael_s_campbell

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2



Sat, 30 Apr 2005 23:45:51 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

Quote:

> why not compile the module using LD_RUN_PATH?  relying on LD_LIBRARY_PATH is
> evil ;-)

Why is that?  In any event, the problem is that when loading C
extensions, ruby doesn't seem to be respecting the LD_LIBRARY_PATH
setting.  Regardless of the probity of the idea, it's broken, and
needs fixing.

I worked around it by adding /usr/local/staf/lib to /etc/ld.so.conf,
but I don't think that's generally a good idea.

-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
                -- Blair Houghton



Sun, 01 May 2005 01:10:42 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

Quote:

> > why not compile the module using LD_RUN_PATH?  relying on
> > LD_LIBRARY_PATH is
> > evil ;-)

> I've heard this charge levied before; can someone tell me the
> inherent evil in it?

> I'm not doubting anyone, just curious.

this sums it up

  http://www.visi.com/~barr/ldpath.html

mkmf uses LD_RUN_PATH to avoid these problems.  it sets LDSHARED to be
something like 'env LD_RUN_PATH=/usr/local/somepkg/lib gcc -shared' to avoid
the exact problem described earlier in this thread - which is requiring the
user/program to manage it's own binary dependancies.  i think of it like
having instance variable associate with an object : when the search path is
encoded in a shared library that 'object' knows it's own depends.  it does not
rely on user code to manage them.

-a

Quote:

> =====
> --

> Yahoo IM: michael_s_campbell

> __________________________________________________
> Do you Yahoo!?
> U2 on LAUNCH - Exclusive greatest hits videos
> http://launch.yahoo.com/u2

--

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328

 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================



Sun, 01 May 2005 01:27:05 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

E> Why is that?  In any event, the problem is that when loading C
E> extensions, ruby doesn't seem to be respecting the LD_LIBRARY_PATH
E> setting.  Regardless of the probity of the idea, it's broken, and
E> needs fixing.

 Can you give a complete example for this (configuration, OS, ...)

 I use to test bdb this script

pigeon% cat a.sh
#!/bin/sh
for dir in `ls -d /home/ts/local/db[234]*`
do
    export LD_LIBRARY_PATH=${dir}/lib
    ruby extconf.rb --with-db-prefix=$dir --with-db-version=
    make unknown
    echo
    echo -n "Waiting ... "
    read
    make test 2>&1 | more
    make distclean
done
pigeon%

 It has always worked.

Guy Decoux



Sun, 01 May 2005 01:36:12 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

and from the dlopen man page :

...
NOTES

     If other objects were link-edited with pathname  when  path-
     name  was  built,  that is, the pathname has dependencies on
     other objects, those objects will automatically be loaded by
     dlopen(). The directory search path used to find both  path-
     name and the other needed objects may be affected by setting
     the  environment variable LD_LIBRARY_PATH, which is analyzed
     once at process startup, and from a runpath  setting  within
     the object from which the call to dlopen() originated. These
     search rules will only be applied to path names that do  not
     contain  an  embedded   '/'.  Objects whose names resolve to
     the same absolute or relative path name may  be  opened  any
     number  of times using  dlopen(); however, the object refer-
     enced will only be loaded once into the address space of the
     current process.
...

dlopen is the culprit.

m{*filter*}: do not use LD_LIBRARY_PATH, use runpath encoding.

-a

--

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328

 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================



Sun, 01 May 2005 02:57:04 GMT  
 setting LD_LIBRARY_PATH doesn't seem to work?

Quote:
> Why is that?

see earlier post.

Quote:
> In any event, the problem is that when loading C extensions, ruby doesn't
> seem to be respecting the LD_LIBRARY_PATH setting.  Regardless of the
> probity of the idea, it's broken, and needs fixing.

it is not ruby which is broken

  eg/c > cat liba.c
  int a;

  eg/c > cat libb.c
  int b;
  extern int a;

  eg/c > gcc -o liba.so -shared liba.c

  eg/c > gcc -o libb.so -shared libb.c -L ./ -la

  eg/c > ldd liba.so
          libc.so.6 => /lib/libc.so.6 (0x4000b000)
          /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

  eg/c > ldd libb.so
          liba.so => not found
          libc.so.6 => /lib/libc.so.6 (0x4000b000)
          /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

so liba.so has NO depends, and libb.so HAS depends.

now a program to dlopen them :

  eg/c > cat dlopen.c
  #include <stdlib.h>
  #include <stdio.h>
  #include <dlfcn.h>

  int
  main (int argc, char **argv)
  {
    char *ld_library_path;

    /* set LD_LIBRARY_PATH if arg given */
    if (argc > 1)
    {
      printf ("SET LD_LIBRARY_PATH TO : %s\n", argv[1]);
      setenv ("LD_LIBRARY_PATH", argv[1], 0);
    }

    /* print LD_LIBRARY_PATH if env has it */
    if (ld_library_path = getenv ("LD_LIBRARY_PATH"))
    {
      printf ("LD_LIBRARY_PATH : %s\n", ld_library_path);
    }

    /* try to open liba.so */
    if ((dlopen ("liba.so", RTLD_NOW|RTLD_GLOBAL)) == NULL)
    {
      printf ("FAILED TO LOAD 'liba.so'\n");
    }
    else
    {
      printf ("SUCCESSFULLY LOADED 'liba.so'\n");
    }

    /* try to open libb.so - which depends on a*/
    if ((dlopen ("libb.so", RTLD_NOW|RTLD_GLOBAL)) == NULL)
    {
      printf ("FAILED TO LOAD 'libb.so'\n");
    }
    else
    {
      printf ("SUCCESSFULLY LOADED 'libb.so'\n");
    }

    return 0;
  }

now using it

  eg/c > dlopen
  FAILED TO LOAD 'liba.so'
  FAILED TO LOAD 'libb.so'

  eg/c > dlopen ./
  SET LD_LIBRARY_PATH TO : ./
  LD_LIBRARY_PATH : ./
  FAILED TO LOAD 'liba.so'
  FAILED TO LOAD 'libb.so'

  eg/c > env LD_LIBRARY_PATH=./ dlopen
  LD_LIBRARY_PATH : ./
  SUCCESSFULLY LOADED 'liba.so'
  SUCCESSFULLY LOADED 'libb.so'

so you see, setting LD_LIBRARY_PATH using setenv does not affect dlopen?!
there is probably a reason for this - but it's non-obvious.  using LD_RUN_PATH
or compiling with -rpath always works and is easy to understand and maintain.

it seems as if dlopen uses the environment of the parent process... perhaps
for securtiy?  anyone?  all i know is that every time i play with dlopen and
LD_LIBRARY_PATH i've been confused...

m{*filter*}: stay awasy from LD_LIBRARY_PATH

-a

--

 ====================================
 | Ara Howard
 | NOAA Forecast Systems Laboratory
 | Information and Technology Services
 | Data Systems Group
 | R/FST 325 Broadway
 | Boulder, CO 80305-3328

 | Phone:  303-497-7238
 | Fax:    303-497-7259
 ====================================



Sun, 01 May 2005 02:50:25 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. set VIDEO_MODE_RESTRICTION=CGA doesn't seem to work

2. expect's full_buffer doesn't seem to work

3. ios.gets doesn't seem to work as advertised

4. proc doesn't seem to work in NASM

5. Micro Focus CALL-CONVENTION 8 doesn't seem to work

6. Adagide install doesn't seem to work?

7. Temporarily changing error_reporting()...doesn't seem to work

8. problem with exec: import doesn't seem to work

9. ldap.modify_s doesn't seem to work

10. update doesn't seem to work with scale

11. PROP:HScrollPos set to zero doesn't work

12. iwidgets::combobox selection set doesn't work

 

 
Powered by phpBB® Forum Software