Choosing A Webhost:
A web hosting service is a type of Internet hosting service that allows individuals and organizations to provide their own website accessible via the World Wide Web. Web hosts are companies that provide space on a server they own for use by their clients as well as providing Internet connectivity, typically in a data center. Web hosts can also provide data center space and connectivity to the Internet for servers they do not own to be located in their data center, called colocation. more...
|
Re: how do you link to a different lib location at run time?: msg#00016
|
Subject: |
Re: how do you link to a different lib location at run time? |
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
|
| |