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


Tom Tromey wrote:

"Stan" == Stan Shebs <shebs@apple.com> writes:

<>
Stan> This causes problems for some configure scripts, in particular
Stan> those in libstdc++ and libobjc, which want to be able to run
Stan> executables. It's not entirely clear to me why that's important,
Stan> since the libraries already build and run perfectly fine for
Stan> cross-compilers.

In the cross-compilation case target libraries make assumptions about
the target environment. When compiling natively the configure scripts
take advantage of this and run tests instead.

I understand how configure works - my question is why is there a need for *execution* tests as well as compile and link tests, the latter two being the vast majority of useful configure tests.

But I answered my own question - I simply whacked the libstdc++
test for execution, replaced with "cross_compiling=no". Multilib
libstdc++ builds just fine then, and even better, the config log
and headers look the same(!) for both the 32-bit and 64-bit cases.
So at least with libstdc++ on Darwin, I think are no execution tests
that configure actually needs to run - I think it's just autoconf
boilerplate that's there because it's convenient.

Now, how to parametrize this usefully...

Stan



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