Mailinglist Archive: opensuse-programming (14 mails)

< Previous Next >
Re: [suse-programming-e] LD_RUN_PATH on SUSE 10.x
  • From: Roger Oberholtzer <roger@xxxxxx>
  • Date: Thu, 21 Sep 2006 21:42:31 +0200
  • Message-id: <1158867751.4095.50.camel@xxxxxxxxxxxxx>
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
> > > 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, 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

< Previous Next >