Re: BUG #6732: Build issue when using gettext on FreeBSD 9

The following bug has been logged on the website:

Bug reference: 6732
Logged by: Christian Ullrich
Email address: chris(at)chrullrich(dot)net
PostgreSQL version: 9.1.4
Operating system: FreeBSD 9
Description:

PostgreSQL 9.1 does not build on FreeBSD 9 if --enable-nls and a Heimdal
Kerberos build from ports is used. The build fails due to undefined
references to functions from gettext's libintl.

The reason is a combination of an oversight in PostgreSQL and the choice of
system linker in FreeBSD 9, which is GNU ld 2.17.50.

(It is nevertheless a PostgreSQL issue, not a FreeBSD one. Bear with me for
a minute.)

The PostgreSQL configure script indiscriminately enables the --as-needed
option to the linker if the linker supports it, which GNU ld 2.17.50 in
FreeBSD 9 does. It does not, however, use it in its own library checks. The
configure script therefore fails to detect libintl as required; the check
program links correctly because libintl is pulled in as an indirect
dependency via libgssapi.

There have been two relevant changes in the behavior of GNU ld since version
2.14, which was included in FreeBSD 8:

- Version 2.15 added the --as-needed flag
- Version 2.16 added the --add-needed flag (which was renamed to
--copy-dt-needed-entries in 2.21 and had its default inverted in 2.22)

With GNU ld 2.14 on FreeBSD 8, the build used to succeed because the
dependency on libintl from libgssapi was sufficient. With the first change
in behavior, the build with GNU ld 2.17 on FreeBSD 9 fails because the
configuration check picks up libintl through libgssapi, but in the failing
location (there are several, the first one to be hit is ecpg, but initdb is
affected as well) libgssapi is dropped due to --as-needed and cannot
contribute its dependency on libintl.

With the current version, GNU ld 2.22, the build works again, because the
second change in behavior allows the configure script to detect the need for
libintl, which is then used wherever required.

Proposed workaround: Do not use --as-needed at all.

Proposed fix: Use --as-needed during configure as well, or make its use
predicated on a working linker version (GNU ld 2.22 or later).

chris(at)chrullrich(dot)net writes:
> PostgreSQL 9.1 does not build on FreeBSD 9 if --enable-nls and a Heimdal
> Kerberos build from ports is used. The build fails due to undefined
> references to functions from gettext's libintl.

Ugh.

> Proposed workaround: Do not use --as-needed at all.

Not really acceptable ...

> Proposed fix: Use --as-needed during configure as well, or make its use
> predicated on a working linker version (GNU ld 2.22 or later).

... and I'm not sure I like either of those either. The first seems
likely to introduce as many problems as it fixes, and I don't see a
reasonable way for the script to test whether --as-needed "works"
(for a value of "works" that's rather unclear anyway).

> ... configure therefore fails to detect libintl as required; the check
> program links correctly because libintl is pulled in as an indirect
> dependency via libgssapi.

Could we make the problem go away for you if we changed the order in
which these libraries are probed for? That's a hack, surely, but it
seems like one much less likely to break other working cases than any
of the alternatives you suggest.

regards, tom lane

* Tom Lane wrote:

> chris(at)chrullrich(dot)net writes:

> Could we make the problem go away for you if we changed the order in
> which these libraries are probed for? That's a hack, surely, but it
> seems like one much less likely to break other working cases than any
> of the alternatives you suggest.

To fix this specific issue, it would work to test gettext before
Kerberos. On the other hand, the same thing is going to happen for every
"downward" dependency (where a library higher up in configure depends on
one tested later).

I think I have a pretty good fix: Early in configure, see if the linker
understands --no-copy-dt-needed-entries, or alternatively
--no-add-needed (which is a deprecated name for the same thing). This is
the "light" version of --as-needed: It does not discard unneeded
libraries immediately, but ignores their dependencies. configure
basically works as before, except that indirect dependencies cannot
"hide" required libraries from it anymore.

And a workaround specific to FreeBSD: There is a port for the current
version of binutils (2.22), in which --no-copy-dt-needed-entries is the
default. This can be done relatively easily, by first installing the
binutils port and then installing Postgres with CFLAGS=-B/usr/local/bin .

--
Christian

* Christian Ullrich wrote:

> I think I have a pretty good fix: Early in configure, see if the linker
> understands --no-copy-dt-needed-entries, or alternatively
> --no-add-needed (which is a deprecated name for the same thing). This is
> the "light" version of --as-needed: It does not discard unneeded
> libraries immediately, but ignores their dependencies. configure
> basically works as before, except that indirect dependencies cannot
> "hide" required libraries from it anymore.

Oh, I should have made this clearer: This works without any modification
to configure or anything else, so configure can still add --as-needed to
the build LDFLAGS.

--
Christian

On tor, 2012-07-12 at 15:25 +0000, chris(at)chrullrich(dot)net wrote:
> The PostgreSQL configure script indiscriminately enables the --as-needed
> option to the linker if the linker supports it, which GNU ld 2.17.50 in
> FreeBSD 9 does. It does not, however, use it in its own library checks. The
> configure script therefore fails to detect libintl as required; the check
> program links correctly because libintl is pulled in as an indirect
> dependency via libgssapi.

> Proposed fix: Use --as-needed during configure as well, or make its use
> predicated on a working linker version (GNU ld 2.22 or later).

Over the weekend I was investigating a separate but related issue on
Debian, which goes like this:

configure with --with-libedit-preferred, or have libedit but not
libreadline installed. Because libedit is linked with libbsd, which
provides setproctitle, the check for function setproctitle succeeds.
Thus, ps_status.c is compiled using the setproctitle variant. When
postgres is linked, however, we don't put libedit on the command line,
so the link fails.

The workaround/solution I came up with was also to put
LDFLAGS=-Wl,--as-needed on the configure command line to run the tests
with that flag as well. With that, the setproctitle test fails.

To add insult to injury, the setproctitle implementation in libbsd is a
stub that doesn't do anything, so we definitely don't want to arrive at
a solution that ends up using it.