Re: when linking on Solaris 64bit shared object using cc, -m64 should be used
On Tue, 10 Jun 2014, Petr Sumbera wrote: And finally I was uncertain with "CC=cc -m64". It appeared to me as something what can cause some troubles and should be rather avoided. In my experience, this has worked best for Solaris. Libtool uses CC (or CXX in the case of C++) for linking. Until such time that libtool implements proper multilib support, this seems like the most reliable solution. It would be wrong for libtool to incorporate a partial solution. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: when linking on Solaris 64bit shared object using cc, -m64 should be used
Dne 10.06.14 16:30, Bob Friesenhahn napsal(a): On Mon, 9 Jun 2014, Petr Sumbera wrote: Hi, I'm often getting following error: /usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la -rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version mod_dtrace.lo ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64 apxs:Error: Command failed with rc=131072 Attached patch fixes the issue. Normally such options should already be included in CFLAGS (or sometimes works better in CC). All of the software needs to be compiled with the same -m64 option. In my case it's included during compilation but not included during linking. When ld is used instead of cc everything works. Also using all CFLAGS during linking seemed to me inappropriate since most of them wouldn't be relevant for linking. And finally I was uncertain with "CC=cc -m64". It appeared to me as something what can cause some troubles and should be rather avoided. When compiling using the Sun compiler and targeting 64-bits, I configure using something like ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ... Libtool is not multilib capable under Solaris. That is, it does not automatically install a library into an architecture-specific subdirectory or search there either. You might notice that the system does support different directories (e.g. '/lib/32', '/lib/64', '/lib/amd64') and GCC is multilib capable, putting its own 64-bit libraries in an architecture-specific subdirectory. Yes. We do following: https://hg.java.net/hg/solaris-userland~gate/file/aaef0df2e4f3/components/apr-1_5/patches/libtool.m4.patch The second part of the patch is to workaround the linking problem I'm trying to find right solution. Thanks, Petr
Re: when linking on Solaris 64bit shared object using cc, -m64 should be used
On Mon, 9 Jun 2014, Petr Sumbera wrote: Hi, I'm often getting following error: /usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la -rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version mod_dtrace.lo ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64 apxs:Error: Command failed with rc=131072 Attached patch fixes the issue. Normally such options should already be included in CFLAGS (or sometimes works better in CC). All of the software needs to be compiled with the same -m64 option. When compiling using the Sun compiler and targeting 64-bits, I configure using something like ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ... Libtool is not multilib capable under Solaris. That is, it does not automatically install a library into an architecture-specific subdirectory or search there either. You might notice that the system does support different directories (e.g. '/lib/32', '/lib/64', '/lib/amd64') and GCC is multilib capable, putting its own 64-bit libraries in an architecture-specific subdirectory. For my own 64-bit compiles under Solaris, I use a different installation prefix in order to make sure that 32-bit and 64-bit libraries/includes are sane. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
when linking on Solaris 64bit shared object using cc, -m64 should be used
Hi, I'm often getting following error: /usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la -rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version mod_dtrace.lo ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64 apxs:Error: Command failed with rc=131072 Attached patch fixes the issue. Note that I'm not libtool expert. Any feedback is welcomed. Thanks, Petr --- build/libtool.m4 +++ build/libtool.m4 @@ -5432,11 +5445,16 @@ solaris*) _LT_TAGVAR(no_undefined_flag, $1)=' -z defs' + for i in $LTCFLAGS; do +case $i in + -m32|-m64) _LT_TAGVAR(addressing_model, $1)="$i";; +esac + done if test "$GCC" = yes; then wlarc='${wl}' - _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag ${wl}-z ${wl}text ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC ${addressing_model} -shared $pic_flag ${wl}-z ${wl}text ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags' _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~ - $CC -shared $pic_flag ${wl}-z ${wl}text ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp' + $CC ${addressing_model} -shared $pic_flag ${wl}-z ${wl}text ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp' else case `$CC -V 2>&1` in *"Compilers 5.0"*) @@ -5447,9 +5465,9 @@ ;; *) wlarc='${wl}' - _LT_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC ${addressing_model} -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $compiler_flags' _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~ - $CC -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp' + $CC ${addressing_model} -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp' ;; esac fi @@ -5719,6 +5737,8 @@ [Commands necessary for finishing linking programs]) _LT_TAGDECL([], [file_list_spec], [1], [Specify filename containing input files]) +_LT_TAGDECL([], [addressing_model], [1], +[Set 32-bit or 64-bit addressing model]) dnl FIXME: Not yet implemented dnl _LT_TAGDECL([], [thread_safe_flag_spec], [1], dnl[Compiler flag to generate thread safe objects])