This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 64-bit configure hell


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]