DSL Ideas and Suggestions :: EUREKA!!!!

I just noticed that $LD_LIBRARY_PATH doesn't always work...apparently some applications ignore this variable.
I'm trying to make a green extension of screen, and a couple of libs are not found:

Code Sample

dsl@box:~$ export LD_LIBRARY_PATH=/opt/screen/lib
dsl@box:~$ ldd /opt/screen/bin/screen
libncurses.so.5 => /lib/libncurses.so.5 (0x40019000)
libelf.so.0 => not found
libutempter.so.0 => not found
libutil.so.1 => /lib/libutil.so.1 (0x40055000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40059000)
libc.so.6 => /lib/libc.so.6 (0x40086000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
dsl@box:~$ echo $LD_LIBRARY_PATH
/opt/screen/lib
dsl@box:~$ ls $LD_LIBRARY_PATH
libelf.so.0 libutempter.so.0

It only seems to work if I run /etc/init.d/mkwriteable
and then copy the files into /lib

Could those be only symlinks in your /opt/screen/lib dir?
Frequently, libs ending in .so.0 are only symlinks, pointing
to some other location..
All your other listed libs have numbers greater than zero,
and they are all found, which is why I thought to ask..

I usually see these files/symlinks grouped.

libelf.so.0 => libelf.so.0.6.4
libutempter.so.0 => libutempter.so.0.5

And yes.., you are correct..
Depending on how an application was compiled,
or even if the author went to the effort of allowing alt paths,
some apps simply will not run without seeing files in certain places.

This is no fault of the extension, the OS, or the libs,
and can often be worked around by setting a more proper
path for your design in the configure file before compile-time.

Here is some more data, from a "sun" perspective,
on how it can work for you, against you, not at all,
or even as a necessity to an app even running..
http://www.visi.com/~barr/ldpath.html

Again, if you recompile, you can usually set the lib path to your wishes..

I've also seen where a path statement is forced by editing the global path to include checking the LD_LIBRARY_PATH first,
like PATH=$LD_LIBRARY_PATH,$PATH
Which forces a search for libs to check thru your LD_LIBRARY_PATH variable BEFORE your usual path,
which may prevent the error - that it did not find it in the
suggested or usual compiled-in path location.

73
ke4nt

Quote

Could those be only symlinks in your /opt/screen/lib dir?

No, they were files I added myself. Those same files worked when copied into /lib after mkwriteable.

Quote

can often be worked around by setting a more proper path for your design in the configure file before compile-time.

I tried LDFLAGS=-L/opt/screen/lib during configure, but it apparently didn't help. I've noticed some configure scripts are a bit more flexible than others...screen didn't seem to have many options.

Quote

Here is some more data, from a "sun" perspective

I read something similar not long ago, which made me start thinking about alternatives. What I've come up with so far is a confirmation of the old "the more I learn, the more I learn how much more I have to learn".

Quote

I've also seen where a path statement is forced by editing the global path to include checking the LD_LIBRARY_PATH first,
like PATH=$LD_LIBRARY_PATH,$PATH

I didn't know the two paths could work together like that...always thought PATH was for executables and LD_LIBRARY_PATH was for libs, and never the twain shall meet...I'll have to try that out, thanks.

Quote

I've also seen where a path statement is forced by editing the global path to include checking the LD_LIBRARY_PATH first,
like PATH=$LD_LIBRARY_PATH,$PATH

I didn't know the two paths could work together like that...always thought PATH was for executables and LD_LIBRARY_PATH was for libs, and never the twain shall meet...I'll have to try that out, thanks.

You may be correct about the path/exec never meeting,
as I cannot find any further documentation to support this.
I may be following someone else's bad advice or example here
that I came across, or perhaps I am using improper syntax.
This works great with the PYTHONPATH statements,
but those are executables or 'py files as well.
I'll forward this issue to an 'email committee" , and collect their thoughts,
while I continue to search for other information on the lib paths.

73
ke4nt

I think I fixed it.
I tricked the compiler by moving the libs out of /usr/lib and into /opt/screen/lib (rather than just copying), and putting them back after compiling. I haven't tested yet, but I'm guessing that if those were the only libelf and libutempter available, and the compile succeeded, then it should look for the libs in that directory at runtime.

This might be a useful method for avoiding LD_LIBRARY_PATH in the future.

Next Page...
original here.