So I just updated my x86_64 machine to Fedora Core 6, and I find that
rebuilding our CVS HEAD gives a batch of noise that was not there
before:

/usr/bin/ld: skipping incompatible /usr/lib/libtcl8.4.so when searching for -ltcl8.4
/usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
/usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libieee.a when searching for -lieee
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

It turns out that this is because the link command for pltcl includes
-L/usr/lib, so that gets searched before /usr/lib64. And the reason the
command includes that is that that's what it says in TCL_LIB_SPEC in
/usr/lib/tclConfig.sh. There is also a /usr/lib64/tclConfig.sh which
says the right things, but we aren't finding that because this is how we
determine where to look for tclConfig.sh:

$ echo 'puts $auto_path' | tclsh
/usr/share/tcl8.4 /usr/share /usr/lib /usr/lib64
$

Perhaps I should lobby the Red Hat guys to change the order of that
result, but really this is more our problem than theirs: whichever
way tclsh reports it, it will be wrong for trying to build Postgres
with the other word width on a multilib machine.

The ideal thing would be to try to verify that the found tclConfig.sh
is compatible with the compiler switches we want to use, but I can't
think of any reasonably robust way to do that (ie, something that's
likely to work with non-gcc compilers...). Any ideas?

regards, tom lane

Search Discussions

  • Joe Conway at Mar 16, 2007 at 8:53 am

    Tom Lane wrote:
    It turns out that this is because the link command for pltcl includes
    -L/usr/lib, so that gets searched before /usr/lib64. And the reason the
    command includes that is that that's what it says in TCL_LIB_SPEC in
    /usr/lib/tclConfig.sh. There is also a /usr/lib64/tclConfig.sh which
    says the right things, but we aren't finding that because this is how we
    determine where to look for tclConfig.sh:

    $ echo 'puts $auto_path' | tclsh
    /usr/share/tcl8.4 /usr/share /usr/lib /usr/lib64
    $

    Perhaps I should lobby the Red Hat guys to change the order of that
    result, but really this is more our problem than theirs: whichever
    way tclsh reports it, it will be wrong for trying to build Postgres
    with the other word width on a multilib machine.
    Not the ideal answer, but I've had this in my config script for quite a
    while now:

    --with-tclconfig=/usr/lib64

    Joe

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 16, '07 at 1:08a
activeMar 16, '07 at 8:53a
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Joe Conway: 1 post Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase