I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib. If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run. IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH. -- Roger Oberholtzer
I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib.
If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run.
IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH. I'm nearly out the door. Make sure you build with -L<path to correct libraries> You can also use the -rpath command line flag for force the specific
On Wednesday 20 September 2006 4:35 pm, Roger Oberholtzer wrote: libraries into the program so it will pick up the right library at run time. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wed, 2006-09-20 at 16:45 -0400, Jerry Feldman wrote:
I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib.
If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run.
IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH. I'm nearly out the door. Make sure you build with -L<path to correct libraries> You can also use the -rpath command line flag for force the specific
On Wednesday 20 September 2006 4:35 pm, Roger Oberholtzer wrote: libraries into the program so it will pick up the right library at run time.
I am trying to accomplish installing applications anywhere. Then set the path to their libraries in files in /etc/ldconfig.d. So, I do not know the directory to set when it is compiled. Of course, I do set the default install location when compiling. But if the install is elsewhere, I need ldconfig. If I could only control the order of checking that the dynamic loader will use. I really want the system libs to be checked first. Any libs in files in /etc/ldconfig.d should be checked after those in /etc/ld.so.conf, which in turn should be checked after those that are 'built in'. Instead, it seems that when ldconfig builds the cache, it finds a library and remembers the last place it was found. I guess my options are to contact the maker of the package with the offending (depending on your POV) library. It is ActiveState's Tcl package. Which is really a great package! Except for it's flawed libxml2 library... -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
On Wednesday 20 September 2006 22:35, Roger Oberholtzer wrote:
I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib.
If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run.
IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH.
I am confused. LD_RUN_PATH is used during compilation, not during execution, as far as I'm aware. The runtime version is LD_LIBRARY_PATH Why not write a wrapper script for your app, that includes the line export LD_LIBRARY_PATH=/path/to/your/lib and then runs the application.
On Wed, 2006-09-20 at 22:59 +0200, Anders Johansson wrote:
I am confused. LD_RUN_PATH is used during compilation, not during execution, as far as I'm aware. The runtime version is LD_LIBRARY_PATH
LD_RUN_PATH results in information being added to the built executable that will tell it where to look for libs at runtime, independent of any places told at runtime. It becomes part of the binary. Hence the 'RUN' in the name. LD_LIBRARY_PATH is something you can set in the runtime environment that also tells where to look for libraries. It had nothing to do with compilation. -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
On Thu, 2006-09-21 at 08:23 +0200, Roger Oberholtzer wrote:
On Wed, 2006-09-20 at 22:59 +0200, Anders Johansson wrote:
I am confused. LD_RUN_PATH is used during compilation, not during execution, as far as I'm aware. The runtime version is LD_LIBRARY_PATH
LD_RUN_PATH results in information being added to the built executable that will tell it where to look for libs at runtime, independent of any places told at runtime. It becomes part of the binary. Hence the 'RUN' in the name.
LD_LIBRARY_PATH is something you can set in the runtime environment that also tells where to look for libraries. It had nothing to do with compilation.
I'm not entirely sure why you felt you had to repeat what I said, but the point of my email was: why not create a wrapper script for your application that does export LD_LIBRARY_PATH=/path/to/your/library and then executes the application that needs the special lib This seems like a much nicer solution than to add extra directories to ld.so.conf for one particular app (and it beats the living daylights out of hardcoding the path to the lib at compile time)
On Thu, 2006-09-21 at 19:19 +0200, Anders Johansson wrote:
On Thu, 2006-09-21 at 08:23 +0200, Roger Oberholtzer wrote:
On Wed, 2006-09-20 at 22:59 +0200, Anders Johansson wrote:
I am confused. LD_RUN_PATH is used during compilation, not during execution, as far as I'm aware. The runtime version is LD_LIBRARY_PATH
LD_RUN_PATH results in information being added to the built executable that will tell it where to look for libs at runtime, independent of any places told at runtime. It becomes part of the binary. Hence the 'RUN' in the name.
LD_LIBRARY_PATH is something you can set in the runtime environment that also tells where to look for libraries. It had nothing to do with compilation.
I'm not entirely sure why you felt you had to repeat what I said, but the point of my email was: why not create a wrapper script for your application that does
You are splitting hairs. You said LD_RUN_PATH is not used during execution. I think that is a misleading statement, The information it provides during compilation IS used during execution. Of course, setting it after compilation has no effect.
export LD_LIBRARY_PATH=/path/to/your/library
and then executes the application that needs the special lib
This seems like a much nicer solution than to add extra directories to ld.so.conf for one particular app (and it beats the living daylights out
I cannot realistically wrap the applications in the offending package. Unless it is in some complicated and doomed to fail method, like an update from the packager that wipes out the modifications. So LD_LIBRARY_PATH would need to be a global setting, resulting in the same effect as ldconfig. I think my best bet is to see if I can remove the odd libraries and see if the package's apps will use the system one. I think the system one has more things enabled. -- Roger Oberholtzer
On Thu, 2006-09-21 at 20:09 +0200, Roger Oberholtzer wrote:
export LD_LIBRARY_PATH=/path/to/your/library
and then executes the application that needs the special lib
This seems like a much nicer solution than to add extra directories to ld.so.conf for one particular app (and it beats the living daylights out
I cannot realistically wrap the applications in the offending package. Unless it is in some complicated and doomed to fail method, like an update from the packager that wipes out the modifications.
This I didn't understand at all. You are compiling the applications, aren't you? So we're not talking about modifying prepackaged software. So why not, as the final stage, make the name of the executable "name-bin" and make "name" be a script that exports the ld library path variable and then executes name-bin. This is not particularly complex, and it's far better than putting obscure specialty libraries in ld.so.conf, and it's far far better than hard coding It is, in fact, the method already used by many applications, such as mozilla and open office. Are they doomed to fail?
On Thu, 2006-09-21 at 21:22 +0200, Anders Johansson wrote:
On Thu, 2006-09-21 at 20:09 +0200, Roger Oberholtzer wrote:
export LD_LIBRARY_PATH=/path/to/your/library
and then executes the application that needs the special lib
This seems like a much nicer solution than to add extra directories to ld.so.conf for one particular app (and it beats the living daylights out
I cannot realistically wrap the applications in the offending package. Unless it is in some complicated and doomed to fail method, like an update from the packager that wipes out the modifications.
This I didn't understand at all. You are compiling the applications, aren't you? So we're not talking about modifying prepackaged software.
Nope. It is pre-packaged. ActiveState's Tcl package. It is the one that contains the mutant (IMO) libxml2 library that has the exact same name as one in /usr/lib. To make all the other libraries it provides available, I also wind up making it's libxml2 available. Due to the oddities of ldconfig, I cannot make programs use the libxml2 in /usr/lib. BTW, I would use the SUSE Tcl stuff. If it was more complete and available on multiple platforms: the ActiveState distro is also available under Windows and MacOS. So I can have the same packages available on all these platforms. Such cross-platform support is, of course, not the point of SUSE Linux.
So why not, as the final stage, make the name of the executable "name-bin" and make "name" be a script that exports the ld library path variable and then executes name-bin.
This is not particularly complex, and it's far better than putting obscure specialty libraries in ld.so.conf, and it's far far better than hard coding
It is, in fact, the method already used by many applications, such as mozilla and open office. Are they doomed to fail?
I fully understand the concept and have used it in the past with local software. Moxilla and OO each contain a few programs. And, this script wrapper is provided by the packager, and so will stay as needed across updates. The ActiveState Tcl package contains many dozen sub-packages, all with executable scripts and ELF binaries. Wrapping them all is not something I would look forward to. -- Roger Oberholtzer
Hi Roger, I had a similar problem with an older of arkeia which only ran with GLIB v2.0 and required LD_ASSUME_KERNEL to be set, my solution was to use a wrapper script that set the relavent environment variables before calling the original executable. The script works by renaming the original executable and then creating a symlink of the same name to the wrapper script, which sets the variables and then calls the original exec. The install/uninstall function does not delete the original exec. The script also takes care of passing any return codes back to the calling environment. I've attached the wrapper script in case it is useful. 1. Put the script in /usr/local/bin or wherever 2. If you change the script name or put it anywhere else then edit the line SRC= accordingly (this step is very important or it doesn't work). 3. To "wrap" the executable type: wrapper_glib20.sh install <path/program name> 4. To remove the wrapper type: wrapper_glib20.sh uninstall <path/program name> E.g. If we had a program called "/bin/weirdlibs" then the syntax would be: wrapper_glib20.sh install /bin/weirdlibs Or, wrapper_glib20.sh uninstall /bin/weirdlibs The executable is called as before by it's original name. Although the example wrapper is for LD_ASSUME_KERNEL you could modify it to set LD_RUN_PATH or similar. I'm sure there is a more elegant method and a better written script but this works for me. Rgds, Simon
-----Original Message----- From: Roger Oberholtzer [mailto:roger@opq.se] Sent: Wednesday, September 20, 2006 22:35 To: suse-programming-e@suse.com Subject: [suse-programming-e] LD_RUN_PATH on SUSE 10.x
I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib.
If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run.
IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH.
-- Roger Oberholtzer
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e
participants (4)
-
Anders Johansson -
Jerry Feldman -
Roger Oberholtzer -
THORNTON Simon