sparc64: -m64 implies -mlong-double-64

sparc64: -m64 implies -mlong-double-64

[Jan Engelhardt]

Hi,


I observe that -m64 throws an error on the given configuration:

$ touch x.c
$ gcc -m64 x.c
x.c:1: error: -mlong-double-64 not allowed with -m64
$ gcc -v
Using built-in specs.
Target: sparc64-unknown-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++ --enable-checking=release 
--with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp 
--disable-libssp --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --program-suffix=-4.4 
--enable-linux-futex --without-system-libunwind --with-cpu=ultrasparc 
--with-long-double-128 --build=sparc64-unknown-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839]

Not specifying -m64 at all, also producing a 64-bit object (by virtue
of --with-cpu=ultrasparc I suppose) has no problem:

$ gcc -c x.c
$ file x.o
x.o: ELF 64-bit MSB relocatable, SPARC V9, relaxed memory ordering, 
version 1 (SYSV), not stripped

How can I resolve the error?


thanks,
Jan

Re: sparc64: -m64 implies -mlong-double-64

[Jan Engelhardt]

On Friday 2009-12-11 23:23, Jan Engelhardt wrote:
>
>I observe that -m64 throws an error on the given configuration:
>
>$ touch x.c
>$ gcc -m64 x.c
>x.c:1: error: -mlong-double-64 not allowed with -m64

Replying to myself and the archive:

The error can show up if one tries to use the sparc64-defaulting gcc 
frontend with a sparc32-defaulting(sparc64-capable) cc1. Pointing the 
gcc64 to the right cc1 using -B/appropriate/prefix solves it for me.

Background: Let /ch be a chroot environment with a gcc64. When calling 
/ch/usr/bin/gcc, -B may be needed. Some distributions have cc1 in 
usr/lib/gcc rather than usr/libexec/gcc. Where this is the case, the gcc 
frontend seems to use a relative pathspec "../lib/gcc" (observed on 
openSUSE gcc -v) so that -B is not strictly needed. But it turns out 
Fedora uses an absolute pathspec "/usr/libexec/gcc".