Re: Why are these modules built without respecting my LDFLAGS?

I have a short list of modules that have been built without respecting my
LDFLAGS and/or LDFLAGS_SL. They are as follows:

autoinc.so
citext.so
earthdistance.so
insert_username.so
isn.so
lo.so
moddatetime.so
refint.so
tablefunc.so
timetravel.so
tsearch2.so

I have looked around in the documentation and the source code, but have found
nothing enlightening.

Is there a way to force them to be built with my LDFLAGS? Is it a bad idea? If
so, why?

Sincerely,
Aaron W. Swenson

"Aaron W. Swenson" <aaron(dot)w(dot)swenson(at)gmail(dot)com> writes:
> I have a short list of modules that have been built without respecting my
> LDFLAGS and/or LDFLAGS_SL.

It's difficult to comment on this since you haven't told us what flags
you wanted to inject, nor exactly how you tried to inject them, nor what
version of PG you're working with, nor what platform you're on. But
generally speaking I'd expect the values of those variables set by
configure to be used in linking all contrib modules.

regards, tom lane

On Sunday 27 June 2010 10:26:48 you wrote:
> "Aaron W. Swenson" <aaron(dot)w(dot)swenson(at)gmail(dot)com> writes:
> > I have a short list of modules that have been built without respecting my
> > LDFLAGS and/or LDFLAGS_SL.
>
> It's difficult to comment on this since you haven't told us what flags
> you wanted to inject, nor exactly how you tried to inject them, nor what
> version of PG you're working with, nor what platform you're on. But
> generally speaking I'd expect the values of those variables set by
> configure to be used in linking all contrib modules.
>
> regards, tom lane
>

Thank you for the quick response. I apologize for leaving out some pertinent
information.

OS = Gentoo Linux
CPU = AMD Athlon XP-M x86
LDFLAGS = -Wl,-O1,--hash-style=gnu
LDFLAGS_SL = ${LDFLAGS}
PgSQL = 8.4.4

LDFLAGS and LDFLAGS_SL are exported as environment variables that ./configure
does pick up, and pg_config confirms this. (pg_config also reveals that '--as-
needed' is tacked onto LDFLAGS, which isn't a problem.)

"Aaron W. Swenson" <aaron(dot)w(dot)swenson(at)gmail(dot)com> writes:
> LDFLAGS and LDFLAGS_SL are exported as environment variables that ./configure
> does pick up, and pg_config confirms this. (pg_config also reveals that '--as-
> needed' is tacked onto LDFLAGS, which isn't a problem.)

OK, so after some digging I find that, while most of the .so's in our
build are made using Makefile.shlib, pgxs's "MODULES" build rules don't
use that. Instead they rely on the "%.so: %.o" (and platform-specific
variants of that) rules found in src/makefiles/Makefile*. And on most
platforms we've neglected to include LDFLAGS_SL in those rules. This
seems like an oversight, especially since the one platform that has
nonempty LDFLAGS_SL by default (AIX) does include LDFLAGS_SL.

This seems like a clear bug. I'm hesitant to back-patch a change like
that, but not hesitant to fix it in HEAD.

Another thing that I notice is that it's unclear whether a
shared-library link should include LDFLAGS too, or only LDFLAGS_SL.
On AIX we seem to include both of those flag sets (according to both
Makefile.aix and Makefile.shlib) but most other platforms are not
including LDFLAGS in shlib link commands. But Makefile.hpux is off
in left field, as it includes LDFLAGS but not LDFLAGS_SL. Just to
confuse matters even more, Makefile.shlib goes out of its way to pull -L
switches (only) out of LDFLAGS and include those into shlib links.

Should we try to make that a bit more consistent, and if so how?
The shenanigans in Makefile.shlib would get a lot simpler if we said
that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would
think that that would carry substantial risk of breakage. Surely there
are cases where linker switches are appropriate for making executables
but not shlibs. Perhaps we should set up three variables instead of
two, viz
LDFLAGS = switches for linking both executables and shlibs
LDFLAGS_EX = extra switches for linking executables only
LDFLAGS_SL = extra switches for linking shlibs only
Then we could get rid of that untrustworthy hack for extracting -L
switches ...

regards, tom lane

On sön, 2010-06-27 at 19:41 -0400, Tom Lane wrote:
> OK, so after some digging I find that, while most of the .so's in our
> build are made using Makefile.shlib, pgxs's "MODULES" build rules
> don't
> use that. Instead they rely on the "%.so: %.o" (and platform-specific
> variants of that) rules found in src/makefiles/Makefile*. And on most
> platforms we've neglected to include LDFLAGS_SL in those rules. This
> seems like an oversight, especially since the one platform that has
> nonempty LDFLAGS_SL by default (AIX) does include LDFLAGS_SL.
>
> This seems like a clear bug. I'm hesitant to back-patch a change like
> that, but not hesitant to fix it in HEAD.

I think this issue is brought up about once a year. You might want to
review previous discussions.

Tom Lane wrote:

> Should we try to make that a bit more consistent, and if so how?
> The shenanigans in Makefile.shlib would get a lot simpler if we said
> that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would
> think that that would carry substantial risk of breakage. Surely there
> are cases where linker switches are appropriate for making executables
> but not shlibs. Perhaps we should set up three variables instead of
> two, viz
> LDFLAGS = switches for linking both executables and shlibs
> LDFLAGS_EX = extra switches for linking executables only
> LDFLAGS_SL = extra switches for linking shlibs only
> Then we could get rid of that untrustworthy hack for extracting -L
> switches ...

While we're on the subject... this reminds me of another issue that's
come up a few times on the PostGIS mailing lists.

AFAICT pg_config doesn't have a method for generating LDFLAGS for libpq
client applications, only backend libraries with pg_config --libs.
Normally we just go for "-lpq" but that doesn't always seem to work on
platforms where you need to explicitly give all libpq dependencies
during link time, e.g.
http://postgis.refractions.net/pipermail/postgis-users/2010-April/026349.html.

Would LDFLAGS_EX in this case be what we need? If so, could it be
exposed via a pg_config --libpq option or similar?

ATB,

Mark.

--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On sn, 2010-06-27 at 19:41 -0400, Tom Lane wrote:
>> OK, so after some digging I find that, while most of the .so's in our
>> build are made using Makefile.shlib, pgxs's "MODULES" build rules
>> don't
>> use that. Instead they rely on the "%.so: %.o" (and platform-specific
>> variants of that) rules found in src/makefiles/Makefile*. And on most
>> platforms we've neglected to include LDFLAGS_SL in those rules. This
>> seems like an oversight, especially since the one platform that has
>> nonempty LDFLAGS_SL by default (AIX) does include LDFLAGS_SL.

> I think this issue is brought up about once a year. You might want to
> review previous discussions.

I dug around in the archives a bit and failed to find much of any
discussion since the original addition of LDFLAGS_SL in 2004. I did
find a couple of things showing the reasons why AIX has LDFLAGS_SL
there, eg,
http://archives.postgresql.org/pgsql-bugs/2005-12/msg00061.php
but that just confirms my feeling that Makefile.aix has this right
and the other platforms are a brick shy of a load.

Do you have any specific objection to the proposal I made, ie

LDFLAGS = switches for linking both executables and shlibs
LDFLAGS_EX = extra switches for linking executables only
LDFLAGS_SL = extra switches for linking shlibs only

which'd imply adding LDFLAGS and LDFLAGS_SL to all the .o-to-.so rules?

regards, tom lane