[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autotools not suited to proprietary development?

From: Andre Stechert
Subject: Re: autotools not suited to proprietary development?
Date: Wed, 4 Oct 2006 21:33:09 -0700

On Oct 4, 2006, at 8:55 PM, Ryan McDougall wrote:

However the problem remains that Im at a bit of a loss how to ship a
shared .SO library easily. If I build on my machine (or a set of
supported build machines) then the build will link to my prefix (lets
say /usr/lib) and the end user has no choice where he wants to place his

This can be hard to do portably but not because of the autotools. I think it
boils down to two kinds of problems:

1) If your build is libtoolized, then you may end up with -rpath references in your .la files (Google for "debian rpath" to get a sense of the drama that's followed this issue over the years). If you're just distributing the .so's, then this isn't so much of a problem, as you can fix it by having your users install the .so wherever they want, but they have to reference by augmenting their
LD_LIBRARY_PATH appropriately.  OS X dylibs have their install names
embedded and references to them are by full path, so they will still be
problematic. There are ways around this, but they involve a fair amount of
binary hackery on the mach-o format.

2) If your library needs to be aware of its own install location (e.g., it's pretty common for software to make references to files relative to their install paths) and you're trying to keep things simple by distributing just a .so, the only answer is to hard code the install location. This obviously would cause a problem as well, but you're in control of that (maybe stick the location into a
config file or an environment variable).

In summary, if you're careful about it, you can do exactly what you propose.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]