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

> Hmm ... out of curiosity, what exactly is your motivation for doing
> that? =A0The 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. =A0It 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