On Tue, 29 Mar 2016, Bernd Edlinger wrote: > 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.
in-tree builds are already "kludges" itself and I don't see the need to support a variety of versions people want to put in there. So maybe this is simply a documentation issue. We _do_ support build against a variety of installed versions. We don't necessarily need to support building with in-tree gmp but not mpfr or mpc, etc. (I think we do, at least kind-of, but these libs have requirements on their versions as well) > 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 ? Very simple - any set of versions that fulfill our needs in passing in-tree builds for all primary and secondary targets (crosses where those are not platforms used as hosts). Of course choosing the "latest" when changing versions makes sense (unless they broke things too badly). Note that in theory we can also put slightly modified versions in infrastructure/ or download a patch in addition to a tarball which we can apply (like moving NO_ASM to config.h). Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
