Re: LD_RUN_PATH not adding paths when building with shared libs

[Tim Mooney]

In regard to: LD_RUN_PATH not adding paths when building with shared libs,...:

>[please cc, as I don't seem to be getting mail from the lists - and my
>subscribe confirm messages are not getting to me]
>
>This is still trying to work out problems on IRIX where a needed library
>is not in the default search path (libgcc_s.so.1).
>
>Tried using LD_RUN_PATH to point to libgcc but that wasn't working
>without using LD_LIBRARY_PATH at run time.
>
>So, it seems like the LD_RUN_PATH path is not used when building our
>project unless we use --disable-shared:
>
>This project uses libtool and automake.  It builds a library that is
>installed using libtools and also a binary linked against that library.
>
>I'm not clear if this is expected beharior or not.  I'd think
>LD_RUN_PATH should be available regardless if building shared or not:
>
>First, if not using --disable-shared my LD_RUN_PATH is not set in the
>binary:

Are you assuming LD_RUN_PATH is something that's honored on IRIX because
you've seen it honored on other platforms (e.g. Solaris?).  If you've
seen it documented somewhere that it should work on IRIX, can you provide
information on where I should look?

The reason I'm asking is because I've never seen LD_RUN_PATH referenced
on IRIX, and I thought I understood shared libraries on IRIX fairly well.

LD_RUN_PATH isn't mentioned in the ld man page.  If it's actually honored
by the linker, you should be able to create a very simple C test program,
copy your shared C library (for the ABI you're compiling for) into a
temporary directory like /tmp/test-run-path, set the LD_RUN_PATH variable
to point to that directory, and then compile your C program and link it
against that copy of the shared C library.

If ldd or elfdump turn up an `RPATH' in the binary, then LD_RUN_PATH was
probably honored.  If not, it probably wasn't.

In my tests, it looks like it's not honored, which matches my experiences.

>address@hidden:~/swish-e$ ./configure --prefix=$HOME/test_again >/dev/null
>address@hidden:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make 
>install >/dev/null
>address@hidden:~/swish-e$ strings /home/moseley/test_again/bin/swish-e | grep 
>moseley
>/home/moseley/test_again/lib
>/home/moseley/test_again/lib/swish-e
>
>(By the way, I'm sure I used to know a better way to show the search
>path for a binary than using strings!)

I generally use `ldd', though `elfdump' is also a useful tool on IRIX,
assuming you're talking about the runpath (RPATH or DT_RPATH) that the
loader uses.

>Now try with --disable-shared:
>
>address@hidden:~/swish-e$ ./configure --disable-shared 
>--prefix=$HOME/test_again >/dev/null
>address@hidden:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make 
>install >/dev/null
>address@hidden:~/swish-e$ strings /home/moseley/test_again/bin/swish-e | grep 
>moseley
>/home/moseley/swish-e/filters
>/home/moseley/test_again/lib/swish-e
>
>Now LD_RUN_PATH is getting in the binary.  Is this expected?

You don't know that it's LD_RUN_PATH that's causing
/home/moseley/swish-e/filters to appear in the binaries, though, do you?
Couldn't be that it's getting in there because of some other reason?

>If it is expected how should users that have other library requirements
>(like libgcc on IRIX) add in a path at build time?

If the library doesn't specify it itself, the only way I'm aware of is
via the `-rpath' option of ld.  The linker will include the RPATH from
libraries in the binary it generates, though, so you wouldn't need -rpath
when linking your binary if libgcc_s.so.N internally specified an RPATH
for where to find it and its dependencies.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164