On Thu, Aug 28, 2003 at 05:36:50PM -0500, Tim Mooney wrote: > 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? I don't have access to the IRIX machine -- that was something that came from the person I was trouble shooting for -- I've asked him to try a simple test with LD_RUN_PATH and report back. > >Now try with --disable-shared: > > > >moseley@bumby:~/swish-e$ ./configure --disable-shared --prefix=$HOME/test_again >/dev/null > >moseley@bumby:~/swish-e$ LD_RUN_PATH=/home/moseley/swish-e/filters make install >/dev/null > >moseley@bumby:~/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? No, it's not in there for any other reason because it's just some random directory I picked and LD_RUN_PATH was the only change I made. You are right that I'm not 100% sure that it's in there because LD_RUN_PATH (LD_RUN_PATH in the environment might be causing something else to happen along the way, true). > >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. I guess I'm not following. That's probably my fault because I don't know this stuff well, and only on a few platforms. Basically, what happened was someone tried to build the package and it said at link time: rld: Fatal Error: Cannot Successfully map soname'libgcc_s.so.1' under any of the filenames But they had that on their system. I suggested that they try LD_RUN_PATH to point to the location of libgcc, which would be a normal way to extend the search path. That didn't work but they reported back that using LD_LIBRARY_PATH worked. Libtool was adding -rpath during the build so I assume that was overriding the LD_RUN_PATH. Assuming is the word there. In my testing (on Linux) I found also that LD_RUN_PATH was not used when I built the package, but if I used --disable-shared I was able to get paths from LD_RUN_PATH into the binary. That also worked on the IRIX system. The issue is how do I offer help to people trying to build our package on various platforms (and often for people with little experience building from source). Perhaps I depended on LD_RUN_PATH too much to solve problems with libraries in non-standard places in the past. So what seems to have happened is that by using --disable-shared that removed the use of -rpath when linking which let LD_RUN_PATH work. Under normal ./configure && make the link line includes: -Wl,--rpath -Wl,/usr/local/lib but with --disable-shared --rpath is not used. See, it's not entirely obvious (to me, I should say) that LD_RUN_PATH and --disable-shared work against each other. So the question, after all that, is maybe LD_RUN_PATH is the wrong suggestion, and instead I should say: ./configure && make LDFLAGS='-R /path/to/non-standard/library' -- Bill Moseley moseley@xxxxxxxx
