Re: BUG #5351: compiling with --disable-shared is broken (patch included)
От | Craig Ringer |
---|---|
Тема | Re: BUG #5351: compiling with --disable-shared is broken (patch included) |
Дата | |
Msg-id | 4B8DB5C7.5080407@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: BUG #5351: compiling with --disable-shared is broken (patch included) (Jonas Lund <whizzter@gmail.com>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: