Summary: | dev-db/postgresql-{base,server}-8.4.4 ignores LDFLAGS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever> |
Component: | New packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, kfm, patrick, titanofold |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 285475 | ||
Attachments: | Ebuild Patch for LDFLAGS |
Description
Arfrever Frehtes Taifersar Arahesis (RETIRED)
2009-06-20 16:22:22 UTC
dev-db/postgresql-base-8.4.1 also ignores LDFLAGS: * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/postgresql-8.4/lib64/libpq.so.5.2 * /usr/lib64/postgresql-8.4/lib64/libpgtypes.so.3.1 * /usr/lib64/postgresql-8.4/lib64/libecpg.so.6.1 * /usr/lib64/postgresql-8.4/lib64/libecpg_compat.so.3.1 configure: using LDFLAGS= -Wl,--as-needed configure --help says: LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> From the configure.in: # If compiler will take -Wl,--as-needed (or various platform-specific # spellings thereof) then add that to LDFLAGS. So it does respect LDFLAGS, but adds --as-needed by default. What's the best way to proceed with that? (In reply to comment #2) > So it does respect LDFLAGS, but adds --as-needed by default. The code in Portage checks if --hash-style=gnu is respected. > So it does respect LDFLAGS, but adds --as-needed by default. What's the best
> way to proceed with that?
I changed both invocations of emake in src_unpack() to be as follows:
emake LDFLAGS="${LDFLAGS}" LDFLAGS_SL="${LDFLAGS}" || die "emake failed"
After building, I checked the flags:
# pg_config --ldflags
-Wl,-O1,--hash-style=gnu
# pg_config --ldflags_sl
-Wl,-O1,--hash-style=gnu
Problem solved, it would appear. I suppose that means we needn't import toolchain-funcs either.
Also, by default, it augments CFLAGS - and also requires CFLAGS_SL to affect shared libraries - in a similar fashion. But that would be another bug.
I should also add that the above reported flags are exactly as I've defined them in make.conf ;) * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib/postgresql-8.4/lib/autoinc.so * /usr/lib/postgresql-8.4/lib/citext.so * /usr/lib/postgresql-8.4/lib/earthdistance.so * /usr/lib/postgresql-8.4/lib/insert_username.so * /usr/lib/postgresql-8.4/lib/isn.so * /usr/lib/postgresql-8.4/lib/lo.so * /usr/lib/postgresql-8.4/lib/moddatetime.so * /usr/lib/postgresql-8.4/lib/refint.so * /usr/lib/postgresql-8.4/lib/tablefunc.so * /usr/lib/postgresql-8.4/lib/timetravel.so * /usr/lib/postgresql-8.4/lib/tsearch2.so That list is a third of the length than what I was getting before editing the emake line as K. Millar wrote it. (On a side note, the emake line(s) in src_compile(), not src_unpack().) I'm not sure there is much more we can do without a patch or a good reason why PostgreSQL tacks on --as-needed during the compile. I should note that -base did NOT give any QA notices. It was -server that spewed out the above. I've done a bit more digging on this, and it looks like the modules excluded from LDFLAGS(_SL) are experimental functions, or they are already included in the server and those modules are there for backwards compatibility. + 02 Jun 2010; Patrick Lauer <patrick@gentoo.org> + +postgresql-base-7.4.29-r1.ebuild, +postgresql-base-8.0.25-r1.ebuild, + +postgresql-base-8.1.21-r1.ebuild, +postgresql-base-8.2.17-r1.ebuild, + +postgresql-base-8.3.11-r1.ebuild, + +files/postgresql-base-8.4-9.0-heimdal_strlcpy.patch, + +postgresql-base-8.4.4-r1.ebuild, +postgresql-base-9.0_beta1-r1.ebuild: + Fixes for #313765, #251046, #294462, #300793, #274836, #296714, #238817, + #278228, #263096, #246397, #285953. Thanks to Aaron Swenson for collecting + the fixes and testing. dev-db/postgresql-server also needs to be fixed. (In reply to comment #10) > dev-db/postgresql-server also needs to be fixed. > So we should link in modules that are experimental and/or integrated into the server already? Upstream has resolved this bug in 9.0_beta3. They did not back port the patch. I'll get another collection of ebuilds ready, though, that will implement the fix. Good to know! Note however that there's no need to upload a swathe of ebuilds; just an applicable (backported) patch will be sufficient. Aaron: Did you find the time to backport the fix? (In reply to comment #14) > Aaron: Did you find the time to backport the fix? > Yes I did. I've passed it along to Patrick. I've bombarded him with a lot of things when he got back from his vacation. It shouldn't be too long now. Created attachment 254685 [details, diff]
Ebuild Patch for LDFLAGS
The attached patch resolves the LDFLAGS issue for 8.4.4. However, a similar patch to 8.{1,2,3} does not. I haven't been able to figure out why. (I could have sworn it did, but I guess not, or something has changed, or something is wrong with my system.)
The sed statement for the older branches needs to be this instead:
sed -e "s/\(\$(CC) \)\(.*\)/\1\$(CFLAGS) \$(LDFLAGS) \$(LDFLAGS_SL) \2/" \
-i src/makefiles/Makefile.linux
The summary is fixed. As for the other ebuilds, see bug 347005. 21 Mar 2011; Aaron W. Swenson <titanofold@gentoo.org> +postgresql-server-8.2.20-r1.ebuild, +postgresql-server-8.3.14-r1.ebuild, +postgresql-server-8.4.7-r1.ebuild, +postgresql-server-9.0.3-r1.ebuild: Fixes bugs 274836, 302384, 323683, 325709, 347005, 347223, 353687 and 353750. |