Re: how do you link to a different lib location at run time?

["K. Richard Pixley" <rich@xxxxxxxx>]

Robert P. J. Day wrote:

>  other options include working with /etc/ld.so.conf on the new
> system, of course, or using LD_LIBRARY_PATH (although there are
> numerous online essays about why this is a bad idea.)
>
>  what's the standard way to do this?  thanks.
The "standard" way to do this on linux is highly unsatisfactory.

You create a build machine, perhaps a vmware, which is used for nothing 
else but this build.  Build as root.  Install the libraries.  Link 
against them.  And your final build pass aggregates everything you've 
built into one of the binary packaging systems like rpm.  This does have 
the advantage of using a clean build machine for each distinct build.

This is unsatisfactory for a number of reasons.  It's difficult to use 
any form of source control on such a system.  You must maintain numerous 
such "machines" which is a mixed blessing, (vmware makes it easier to 
build for multiple different OS versions, though).  And short of 
reconstructing your build machine with every pass, it's hard to be sure 
you have all the necessary libraries, or suitable licensed replacements, 
available in your binary packages.

For most of the free software world, this is all just skipped, and they 
ship sources instead, forcing the user to sort through these problems.  
Mozilla is one strong exception.

I've used a number of other approaches as well.  Static linking is 
probably the best for commercially supported software as your package is 
no longer vulnerable to the whimsey of random sysadmins and it covers 
most of the licensing problems too.

My favorite approach is a hybrid.  Use the clean machine approach, 
dynamically link against any library supplied by the OS "vendor", supply 
and statically link against any library you need which is not supplied 
by the OS vendor.  If you ship on numerous versions and/or distributions 
of linux, cygwin, bsd, etc, you need to settle in on something like this 
anyway.

This completely avoids the issue of installing or configuring shared 
libraries, which you would only need if the end-user specifically had a 
need for dynamic linking against one of your libraries.  In that case, 
split your distro into two parts, end-user part, and developer part.  
End users usually want turn key systems while developers are usually 
clever enough to figure out how to manage LD_LIBRARY_PATH and such.

--rich