* sparc64: -m64 implies -mlong-double-64
@ 2009-12-12 0:59 Jan Engelhardt
2009-12-12 1:01 ` Jan Engelhardt
0 siblings, 1 reply; 2+ messages in thread
From: Jan Engelhardt @ 2009-12-12 0:59 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: sparc64: -m64 implies -mlong-double-64
2009-12-12 0:59 sparc64: -m64 implies -mlong-double-64 Jan Engelhardt
@ 2009-12-12 1:01 ` Jan Engelhardt
0 siblings, 0 replies; 2+ messages in thread
From: Jan Engelhardt @ 2009-12-12 1:01 UTC (permalink / raw)
To: gcc-help
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".
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-12-12 0:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-12 0:59 sparc64: -m64 implies -mlong-double-64 Jan Engelhardt
2009-12-12 1:01 ` Jan Engelhardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).