Skip site navigation (1) Skip section navigation (2)

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

From: Christian Ullrich <chris(at)chrullrich(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6732: Build issue when using gettext on FreeBSD 9
Date: 2012-07-13 00:00:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
* 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 .


In response to


pgsql-bugs by date

Next:From: Christian UllrichDate: 2012-07-13 00:04:50
Subject: Re: BUG #6732: Build issue when using gettext on FreeBSD 9
Previous:From: Bruce MomjianDate: 2012-07-12 22:49:29
Subject: Re: BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group