pltcl vs. multilib machines

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