On Wed, Dec 10, 2014 at 8:42 AM, Andrew Haley <aph@xxxxxxxxxx> wrote: > On 12/10/2014 02:03 PM, Cyd Haselton wrote: >> On Tue, Dec 9, 2014 at 7:57 AM, Cyd Haselton <chaselton@xxxxxxxxx> wrote: >>> On Mon, Dec 8, 2014 at 10:02 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> 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. > I could do that. You want me to update the download_prerequisites file to use the later versions of gmp and mpfr after you've updated the tarballs at the infrastructure location? You should know, however, that for whatever reason the build only ran through the original error once. I encountered a different error further along in the build, and when I ran "make clean && make MAKEINFO=true" to pick up some changes I'd made in gcc/configure, the build failed in the same place, with the same errors. Apparently I have to run make && make check in the gmp6 build directory in order for the top-level build to run successfully. The only obvious difference I see between only running the top-level build and running a gmp level build, make check, THEN the top level build is that the gmp build creates an additional shared library that's not created when *just* the top-level build is run.
