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
