What happened?
One developer came to me with an error from curl command.$ curl https://www.google.ca
curl: (48) An unknown option was passed in to libcurl
The same command worked well for other accounts on the same host. So the most possible reason is the user had some special environment variables.
Root cause
After basic checking, the root cause was found, LD_LIBRARY_PATH was set in his account's ~/.bash_profile.
$ cat ~/.bash_profile
LD_LIBRARY_PATH=/app/ibm/lib64/
Let's have a look at what shared library was mislinked.
$ ldd $(which curl)
...
libcurl.so.4 => /app/ibm/lib64/libcurl.so.4
...
For other users without LD_LIBRARY_PATH, the result is:
$ unset LD_LIBRARY_PATH
$ ldd $(which curl)
...
libcurl.so.4 => /lib64/libcurl.so.4
...
Even if the name is same, those two .so files are different.
Solution
After removing the LD_LIBRARY_PATH line in ~/.bash_profile, curl worked well.
More Thinking
LD_LIBRARY_PATH is supposed to be used only for debugging during software development. As the paths set by it are searched before the standard library path (/lib, /usr/lib), setting LD_LIBRARY_PATH globally is a very bad practice.
If an application was not linked with proper rpath and its dependencies library files cannot be installed into standard lib path, LD_LIBRARY_PATH may be the only resolution. In this case, the right way is to write a wrapper script file like below to limit LD_LIBRARY_PATH only valid for that particular application.
$ cat app.sh
#!/bin/bash
LD_LIBRARY_PATH=/app/lib /app/bin/app
The perfect solution to a "turn-key application" is linked with relative rpath.
/Installation_Path/bin/app
/Installation_Path/lib/libfoo.so
/Installation_Path/lib/libbar.so
$ gcc -Wl,-rpath,'$ORIGIN'/../lib/ -o app
When /app/bin/app is running, the dynamic linker will search .so files from a relative path based on where the "app" file is located. As a result, the app package can be installed at any location.
Related links:
No comments:
Post a Comment