64-bit configure hell

[Stan Shebs]

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