Why are these modules built without respecting my LDFLAGS?
in [PgSql]
|
Prev: [HACKERS] Why are these modules built without respecting my LDFLAGS?
Next: [HACKERS] pg_dump's checkSeek() seems inadequate
From: Tom Lane on 27 Jun 2010 10:26 "Aaron W. Swenson" <aaron.w.swenson(a)gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Aaron W. Swenson" on 27 Jun 2010 18:38 On Sunday 27 June 2010 10:26:48 you wrote: > "Aaron W. Swenson" <aaron.w.swenson(a)gmail.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.) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 27 Jun 2010 19:41 "Aaron W. Swenson" <aaron.w.swenson(a)gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Mark Cave-Ayland on 28 Jun 2010 05:11 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 3 Jul 2010 18:41
Peter Eisentraut <peter_e(a)gmx.net> writes: > 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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |