This is the mail archive of the
mailing list for the GCC project.
Re: Solaris vtv port breaks x32 build
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Jeff Law <law at redhat dot com>
- Cc: Ulrich Drepper <drepper at gmail dot com>, Matthias Klose <doko at ubuntu dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 02 Dec 2015 13:29:20 +0100
- Subject: Re: Solaris vtv port breaks x32 build
- Authentication-results: sourceware.org; auth=none
- References: <CAOPLpQdoN06fWHOZfZPZEA=oW+9Zba5p70N5=Euyd4V4GpgoMA at mail dot gmail dot com> <565CE267 dot 5000901 at redhat dot com> <CAOPLpQc97V3_6wqZe4Ry+toi3qZHCAPMALRCzS7C8PACiTRqFg at mail dot gmail dot com> <565D026E dot 10105 at redhat dot com> <CAOPLpQfKWCK3=F4p3+eF5XzM4D-m1j35ErLs60U7ihRrmgmW5w at mail dot gmail dot com> <565D4E95 dot 5000507 at ubuntu dot com> <CAOPLpQfKkRbJoMALSVLJpRYdWPwah67y_sjFGPraf+una55z3g at mail dot gmail dot com> <565E6B55 dot 7040708 at redhat dot com>
Sorry for replying so late: I'd been away from my mail for an extended
Jeff Law <email@example.com> writes:
> On 12/01/2015 07:17 AM, Ulrich Drepper wrote:
>> On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose <firstname.lastname@example.org> wrote:
>>> that might be another instance of
>>> Does something like this help?
>> No, same problem as before. This macro doesn't actually generate any
>> code in configure.
> From looking at your configure line, I see that
> --build = x86_64-redhat-linux
> --host = x86_64-redhat-linux
> and no --target
> That to me looks like a native setup and thus I would expect
> $cross_compiling to be "no". Hence the behaviour you're seeing.
Exactly: it would be good if Ulrich could post the canonical build,
host, and target values determined by configure, so we can be sure.
> Essentially you've got a native toolchain, but with one or more multilibs
> that can't actually be executed.
Right: I saw exactly the same behaviour in the distant past when
bootstrapping on an IRIX host that couldn't execute 64-bit binaries or
on Solaris/SPARC with a non-SPARCv9 capable cpu. At that time, the only
workaround was to configure with --disable-multilib.
> Which in turn suggests looking more closely at Matthias's suggestion.
Exactly: moving AM_ENABLE_MULTILIB up as Matthias suggested sets
cross_compiling=maybe for non-default multilibs early, which should
achieve the desired behaviour. All other libraries that invoke both
macros already do so in this order.
Rainer Orth, Center for Biotechnology, Bielefeld University