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