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.
