FC3 broken with HEAD

The recent ld --as-needed patch seems to break psql on FC3: it fails to
start with "symbol lookup error: /usr/lib64/libreadline.so.4: undefined
symbol: BC". You can see this on the FC3 build farm machine:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=viper&dt=2005-05-06%2004:47:01

My current theory on why this happens is the following:

- RH's readline is built so that an application that links against
readline must also link against libtermcap

- libtermcap provides the "BC" symbol which libreadline references

- for some reason that isn't clear to me, ld --as-needed removes the
libtermcap dependency from the generated psql executable; with the
patch, ldd on psql on FC3 shows:

libpq.so.4 => /opt/pg/cvs-die/install/lib/libpq.so.4 (0xb7fd1000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0xb7f8a000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e5f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e31000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7e1d000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7e07000)
/lib/ld-linux.so.2 (0xb7fe8000)

This looks supiciously like an ld bug: -ltermcap is specified on the
link line, and the resulting executable requires it, but ld does not
link against it.

So, it seems we'll need to back out the patch. I think we could probably
still use --as-needed for the rest of the tree (just not with psql), but
that's pretty ugly, and I'm nervous using a linker flag in part of the
tree that we know is broken for another part.

Comments?

I haven't reverted the patch yet as I want to make sure I understand the
situation correctly first. In the meantime FC3 users should be able to
configure --without-readline, or just remove the -Wl,--as-needed stuff
from configure.

-Neil

Neil Conway <neilc(at)samurai(dot)com> writes:
> The recent ld --as-needed patch seems to break psql on FC3: it fails to
> start with "symbol lookup error: /usr/lib64/libreadline.so.4: undefined
> symbol: BC". You can see this on the FC3 build farm machine:

Confirmed here on a pretty-nearly-up-to-date FC3 machine.

> So, it seems we'll need to back out the patch. I think we could probably
> still use --as-needed for the rest of the tree (just not with psql), but
> that's pretty ugly, and I'm nervous using a linker flag in part of the
> tree that we know is broken for another part.

Yeah, we will. Please file a bugzilla entry for this though --- I
concur that it is a linker bug.

regards, tom lane

Tom Lane wrote:
> Yeah, we will. Please file a bugzilla entry for this though --- I
> concur that it is a linker bug.

Okay, patch reverted. The RH bug is here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126

-Neil

On Sat, May 07, 2005 at 04:27:04PM +1000, Neil Conway wrote:
> Tom Lane wrote:
> >Yeah, we will. Please file a bugzilla entry for this though --- I
> >concur that it is a linker bug.
>
> Okay, patch reverted. The RH bug is here:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126

Huh, RH's bugzilla is really slow. Are they using the
PostgreSQL-powered bugzilla?

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Huh, RH's bugzilla is really slow. Are they using the
> PostgreSQL-powered bugzilla?

They are, but I think it's a fairly old version (7.3 IIRC).
I'm still trying to get them to move some internal systems
off 7.1 :-(

regards, tom lane

I think this has more to do with poor architectural decisions made in
bugzilla. Things like storing the entire ticket history in one big record
instead of normalizing it.

This means you can't do anything to a ticket without munging through 10s of k
of data. This also creates problems when multiple people are trying to update
a single ticket at a time.

--
greg