Re: BUG #5351: compiling with --disable-shared is broken (patch included)

The following bug has been logged online:

Bug reference: 5351
Logged by: Jonas Lund
Email address: whizzter(at)gmail(dot)com
PostgreSQL version: 8.4.2 (+others)
Operating system: FreeBSD (generic problem)
Description: compiling with --disable-shared is broken (patch
included)
Details:

I'm compiling with "--disable-shared" on 8.4.2 (worked with 8.3.1) and it
fails with:

gmake[3]: *** No rule to make target `libpq.so.5', needed by
`all-shared-lib'.

When examining Makefile.shlib i noticed that an ifeq clause had been
narrowed down in the file between 8.3.1 and 8.4.2 and now missed a bunch of
"secondary clauses" declaring the "shlib" variable and thus activating the:

all-shared-lib: $(shlib)

makefile rule EVEN IF --disable-shared is enabled and thus not making the
libfile.

This following patch disables those clauses:
------------------------------------------------------
--- Makefile.shlib.orig 2010-02-28 23:15:15.877364960 +0100
+++ Makefile.shlib 2010-02-28 23:08:28.631839830 +0100
@@ -120,6 +120,8 @@
override CPPFLAGS += -DSO_MAJOR_VERSION=$(SO_MAJOR_VERSION)
endif

+ifeq ($(enable_shared), yes)
+
ifeq ($(PORTNAME), aix)
ifdef SO_MAJOR_VERSION
shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
@@ -332,6 +334,8 @@
endif


+endif
+

##
## BUILD

"Jonas Lund" <whizzter(at)gmail(dot)com> writes:
> I'm compiling with "--disable-shared" on 8.4.2 (worked with 8.3.1) and it
> fails with:

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.

The reason I'm being picky about this is that the change in
Makefile.shlib was intentional, and I'm afraid that your change
would break other stuff that works now. I'm not even convinced
that it's a good way of solving your problem --- shouldn't the
all-shared-lib target not get built, if you've disabled shlib
building?

regards, tom lane

> 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).

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, and if you're developing anything seriously you
also need to make a "fat" binary with arm code for the iPhone and x86
for the simulator. (I've worked with some iPhone software recently so
it struck me eventhough i'd personally prolly go with sqlite for that)

What kind of functionality is tied to shared libs ?

If building without shared libs isn't supported anymore then i think
you should disable it altogether in the configure script instead of
letting it be broken. Having options that breaks the build isn't
making anyone happy.

> The reason I'm being picky about this is that the change in
> Makefile.shlib was intentional, and I'm afraid that your change
> would break other stuff that works now.

Yes, it's a big possibility that it breaks something since it's a big
block of things for a bunch of platforms and i was hesitant of
submitting the patch initially for that reason.

Then again.. 2 good reasons why it should go in or the entire thing
should be changed back to as it was before (or have something better
done by someone who knows the makefiles better than me).

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.
2: Shouldn't things mostly not having to do with non-shared libs go
somewhere else than Makefile.shlib ? :)

> I'm not even convinced
> that it's a good way of solving your problem --- shouldn't the
> all-shared-lib target not get built, if you've disabled shlib
> building?

That's the point of the patch however, the "all-shared-lib" rule is
defined in this file as:

all-shared-lib: $(shlib)

and because you have a bunch of platform specific rules setting the
shlib variable even if disable-shared is specified (and thus
triggering the rule without building the lib) it cannot be set if this
rule isn't to be activated.

I'm not 100% familiar with how gmake works but i guess there would be
3 other ways to solve the issue with the last one probably being the
most clean variant.

1: have an "ifeq ($(enable_shared), yes)" declaration around every
definition of "shlib" in the platform specifics, this is bound to be
broken over and over but for separate platforms.
2: "undefine" shlib after the platform specific section (does this
work with gmake?)
3: make the all-shared-lib rule fully conditional or have an
conditional variant without any dependancy (does this work with
gmake?)

regards, Jonas Lund

Jonas Lund <whizzter(at)gmail(dot)com> writes:
> What kind of functionality is tied to shared libs ?

Procedural languages, encoding conversions, walreceiver (in 9.0),
not to mention any sort of add-on such as contrib or pgfoundry modules.

> If building without shared libs isn't supported anymore then i think
> you should disable it altogether in the configure script instead of
> letting it be broken.

+1 from my standpoint. If we did want to continue supporting it we'd
need to think of a way to test it, and I'm not even sure what to test
given the truncated functionality that would be available.

regards, tom lane

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