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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool