Hi Marcel,
* Marcel Martin wrote on Thu, May 11, 2006 at 01:01:36PM CEST:
>
> I'm trying to build a 64-bit library on Solaris 9 SPARC. I'm actually using
> autotools with a larger project, but I could reduce the problem to this small
> test case which uses only libtool:
> $ libtool --mode=link g++ -rpath /usr/local/lib -m64 -o libmini.la \
> -no-undefined -version-info 0:0:0 mini.lo
> g++ -shared -nostdlib
> /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o
> /usr/ccs/lib/values-Xa.o
> /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtbegin.o .libs/mini.o
> -Wl,-R -Wl,/vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3 -Wl,-R
*snip*
> ld: fatal: file .libs/mini.o: wrong ELF class: ELFCLASS64
> ld: fatal: File processing errors. No output written to .libs/libmini.so.0.0.0
> collect2: ld returned 1 exit status
>
> The problem is that incorrect paths are used: For example, instead of
> /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o it should be
> /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/sparcv9/crti.o
> If I change the paths and do the g++ call manually, it works.
>
> I guess this is or has to do with the multilib problem which has come up on
> the list before, but I'm still at a loss at what to do now. Is there a
> solution or a workaround for this problem?
Workaround: create a libtool script designed for 64bit linking only, and
adjust the variables
compiler_lib_search_path
and maybe also
sys_lib_search_path_spec
sys_lib_dlsearch_path_spec
to point to the right directories. These variables are set for the C
compiler at the beginning of the script, and for the C++ and other
compilers at the very end.
A fix is still to be done.
Cheers,
Ralf
___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
