This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 64-bit configure hell
- From: Stan Shebs <shebs at apple dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 25 Nov 2004 12:45:10 -0800
- Subject: Re: 64-bit configure hell
- References: <20041125102826.1cf9ebb5.bkoz@redhat.com>
Benjamin Kosnik wrote:
I think if you search through libstdc++ bugzilla you will find reports
of oddness with x86_64 systems and the 64 bit multilib. To me, if you
have to disable multilibs on 32/64 bit systems to get a working
toolchain, something is wrong.
Exactly.
I haven't paid much attention to these bug reports. Some people have
problems (HJ) and others do not (Jakub, Paolo, others).
If you can provide a real problem description, and examples of the
libstdc++ build/configure hacks you use to work around it, it would be
helpful.
It's hard for anybody outside Apple to reproduce on Darwin right now,
because you need an up-to-the-minute Tiger with all the trimmings,
but you could kludge up a similar situation by taking a standard x86
Linux config and defining a multilib with a -m codegen option that
produces code that can't possibly run on the CPU you're using to
build things. The tools are fine with building shlibs and even
executables for that -m option, but you can't run any of it until
you've moved to the right kind of CPU. (You might have to add code
to the little conftest programs to guarantee the exectime failure,
depending on the -m option you use.)
The crux of the problem seems to be _AC_COMPILER_EXEEXT_WORKS in
autoconf's lang.m4, which looks like it fishes for a usable file
extension by trying to run programs with various names.
Stan