Problem when a 32-bit library is linked instead of a 64-bit library

[Dr. David Kirkby]

On OpenSolaris, like Solaris, the default it to build 32-bit objects. For most 
applications, setting

CFAGS=-m64
LDFLAGS=-m64

configure
make

works.

However, one or two applications don't work well.

In this case.

http://trac.sagemath.org/sage_trac/ticket/7864

lists a build failure in the Sage maths software of libfpll to build. What's 
happening is that it is trying to link a 32-bit library when the build is 
64-bits. So an error


ld: fatal: file /usr/local/gcc-4.4.4-multilib/lib/libstdc++.so: wrong ELF class: 
ELFCLASS32

is reported.

Instead of trying to link to

/usr/local/gcc-4.4.4-multilib/lib/libstdc++.so

it should be linking to the 64-bit version at

/usr/local/gcc-4.4.4-multilib/lib/amd64/libstdc++.so

A workaround it to add -L /usr/local/gcc-4.4.4-multilib/lib/amd64/ -R 
/usr/local/gcc-4.4.4-multilib/lib/amd64/, but that is not a very nice solution. 
It's fine if you happen to know where these libraries are, but many users will 
not. Especially if gcc is installed at some odd location, but a link to 
/usr/bin/gcc is made.

Someone who knows more about libtool than me, suggested adding the --debug 
option, then saving this to a log. Here's the log.

http://trac.sagemath.org/sage_trac/attachment/ticket/7864/libtool-failure.log

is there any way I can get this to build, without resorting to knowing where the 
libraries are. gcc knows where they are, as

/usr/local/gcc-4.4.1-sun-linker/bin/gcc -m64 -print-search-dirs

shows the search path should be the 64-bit directories before the 32-bit ones. 
But that does not seem to be happening.

Any thoughts?

Dave