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