On 29.03.2016 at 10:32, Richard Biener wrote: > On Mon, Mar 28, 2016 at 2:44 PM, Bernd Edlinger > <bernd.edlin...@hotmail.de> wrote: >> >> Hi, >> >> as described in the tracker we have bootstrap problems with in-tree gmp-6.1.0 >> on certain targets, and also a linker issue with check-mpc due to the changed >> mpfr library path. > > Hum, in-tree gmp 6.1.0 is not supported (only the version downloaded by > download_prerequesites is). >
Yes, that is what I thought too, but people out there expect something different, and run into problems. >> These are triggered by overriding CFLAGS and LDFLAGS in in-tree builds. >> It did not happen with the gmp/mpfr/mpc versions that download_prerequisites >> installs, but the currently latest version of these libraries use CFLAGS to >> pass >> -DNO_ASM which is overridden by gcc and causes the gmp-6.1.0 to be >> mis-compiled. > > So you pass down AM_CFLAGS=-DNO_ASM but how does that reliably work > for all gmp versions? > gmp-4.3.2 did use CPPFLAGS=-DNO_ASM, that is not overridden by the build machinery, when I pass AM_CFLAGS=-DNO_ASM it is simply defined twice. gmp-6.1.0 did add -DNO_ASM to CFLAGS, and we break it by overriding CFLAGS. By passing -DNO_ASM in AM_CFLAGS we would un-break this version. Mark Glisse moved recently the -DNO_ASM from CFLAGS to config.h, so that version is immune against overriding CFLAGS and defining AM_CFLAGS=-DNO_ASM is redundant, and does nothing. >> And the mpc issue is triggered by overriding LDFLAGS >> and the changed mpfr library path. So this started with mpfr v3.1.0 which >> moved the sources into a src sub-directory. >> >> The proposed patch fixes these problems by passing -DNO_ASM in AM_CFLAGS, >> and adding both possible mpfr library paths to HOST_LIB_PATH_mpfr. >> I've also adjusted HOST_LIB_PATH_mpc although it did not yet create problems. > > But you remove a possibly good .libs lib_path. No .libs was always wrong as it looks. At least mpc-0.8.1 and mpc-1.0.3 use src/.libs However we do not use that path to link mpc, instead we use: HOST_GMPLIBS = -L$$r/$(HOST_SUBDIR)/gmp/.libs -L$$r/$(HOST_SUBDIR)/mpfr/.libs -L$$r/$(HOST_SUBDIR)/mpc/src/.libs -lmpc -lmpfr -lgmp which does it right. > >> Boot-strapped and regression tested on x86_64-pc-linux-gnu, with different >> gmp versions including the latest snapshot. >> I have additionally built arm cross compilers, which was not working before. >> >> Is this OK for trunk? > > I don't think so. Supporting an arbitrary mix of in-tree versions is > a nightmare. > > If you really want to go down this route see @extra_mpc_gmp_configure_flags@ > and add a variant for the lib-paths. I don't have a good answer for -DNO_ASM > than to fix gmp/mpfr to not pass down this kind of configuation via CFLAGs. > I am afraid, I don't have the power to do that. gmp-6.2.0 will not be affected, but is not yet released. All versions of mpc did pass the configure --with-mpfr-lib option to LDFLAGS which was broken in-tree, but did still work before mpfr 3.1.0 because the LD_LIBRARY_PATH contained mfr/.libs > Please instead do the testing required to ensure bumping the versions > downloaded > by download_prerequesite works during next stage1. > Sure if we only have to support a single gmp-version that would allow us to remove a lot of kludges that are only necessary for gmp-4.3.2 or mpfr before 3.1.0 instead of adding new ones. But which versions will that be? gmp-6.1.0 or gmp-6.2.0 (not yet released) ? mpfr-3.1.4 ? mpc-1.0.3 ? Bernd. > Richard. > >> >> Thanks >> Bernd.