Jonas Lund wrote:
>> Hmm ... out of curiosity, what exactly is your motivation for doing
>> that? The reason we don't test this anymore is that so much of
>> Postgres' functionality is bound up in loadable modules that a build
>> without them seems of little use. It wouldn't even come close to
>> passing the regression tests, for example.
>
> Personally i got sick of having software break after having dependant
> libs changing their ABI's. (Say when having to upgrade some lib that
> is used by an service facing outwards also being used by some internal
> software).
This doesn't force you to use static libraries. All reasonably modern
platforms provide mechanisms to force preferential loading of particular
shared libraries you've provided.
On any modern UNIX, use rpath linking. For Linux, see the "ld.so" man
page, particularly the $ORIGIN expansion token.
On Windows, put the shared libraries in the same directory as the
executable that's loading them, or use WinSxS linking with DLL manifests.
On Mac OS X, use rpath linking, using install_name_tool to change path
references from absolute paths to relative paths inside the application
bundle.
Seriously, static libraries are more pain than they're worth these days
and you have as good or better options with shared library builds.
> When i googled for the problem i also noticed that someone building
> iPhone software had the same problem as me. Apple doesn't allow
> dynamic libraries
I think you must be referring to the fact that iPhone apps aren't
allowed to install dynamically loaded libraries into shared locations
where multiple apps can see them, or the fact that iPhone apps aren't
supposed to dlopen(...) libraries.
There should be no issue with including shared libraries in your
application bundle.
> What kind of functionality is tied to shared libs ?
The server is built around shared library modules.
The client library, libpq, can AFAIK be built statically if you really
must, and shouldn't require shared libraries for anything. The client
library is the only thing that'd make even a remote amount of sense to
use on a device like the iPhone - trying to use the Pg server on the
iPhone is men-in-white-coats crazy.
> 1: This clause is only enabled with --disable-shared being specified
> and as far as i could spot and go through other makefiles i couldn't
> notice any of the rules being used outside unless shared libraries are
> used.
Perhaps offering an option to build *just* libpq, and do that
statically, would be useful to some.
--
Craig Ringer
