GCC 4.9.2 Build Fails at cc1

[Andrew Haley]

On 12/10/2014 02:03 PM, Cyd Haselton wrote:
> On Tue, Dec 9, 2014 at 7:57 AM, Cyd Haselton <chaselton@gmail.com> wrote:
>> On Mon, Dec 8, 2014 at 10:02 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On 8 December 2014 at 14:31, Cyd Haselton wrote:
>>>> Because there's a balance between later stable version and later
>>>> version that works with an in-tree build of GCC/MPFR/MPC.
>>>> My reasoning was that 5.0.0 is the next version up from 4.3.2...which
>>>> is the version specified in download_prerequisites...but that was
>>>> before finding out that version 5.0.0 introduced a bunch of new code.
>>>
>>> But if there are bugs introduced in the jump from 4.y.z to the new
>>> major release 5.0.0 then they will be fixed in 5.0.1, and even more
>>> will be fixed in 5.0.2, and so on.
>>>
>>> In general 5.0.1 will not introduce any new features since 5.0.0, it
>>> will only stabilise it and fix bugs. The same applies to GCC releases.
>>> So your reasoning that keeps leading you to x.y.0 releases is
>>> seriously flawed. x.y.0 is invariably the worst of all x.y.z releases.
>>
>> Just an FYI and as reference for those also building on Android,
>> building gmp6 did complete successfully with one minor edit to one of
>> the source files, referenced here:
>> https://gmplib.org/list-archives/gmp-bugs/2014-July/003510.html
>> In case of link breakage, the edit is to div_qr_1n_pi1.c, and the
>> change involves replacing
>>
>> #if defined (__GNUC__)
>>
>> with
>>
>> #if defined (__GNUC__) && ! defined (NO_ASM)
>>
>> Regarding the overall GCC 4.9.2 build and the error referenced in the
>> original email, I've restarted the top-level build (after running into
>> an error with mpc finding mpfr.h) and will post back if the later
>> versions of gmp and mpfr resolved it.
> 
> As promised, posting back to report that the following reeolved the
> original issue:
> 1.  Using gmp6 and recommended version of mpfr
> 2.  With gmp6, it was necessary to copy the newly made library to the
> location specified in my library path in order for the tests to run
> successfully and for the gcc in-tree build to not throw various __gmpn
> unresolved errors.  This may be due to the fakechroot environment in
> which i'm running the build.

Excellent.

Having to copy the library is expected if it's a dynamic shared object.
This isn't needed if it's built in-tree because we link statically with
it.

Can you help us fix GCC?  I'd like to update download_prerequisites
so that it works with an Android host.

Andrew.