pltcl vs. multilib machines

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pltcl vs. multilib machines
Дата
Msg-id 28927.1174007291@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: pltcl vs. multilib machines  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dawid Kuroczko"
Дата:
Сообщение: Re: [RFC] CLUSTER VERBOSE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: UPDATE using sub selects