marc.glisse at inria.fr
Tue May 3 22:01:29 CEST 2011
On Tue, 3 May 2011, Torbjorn Granlund wrote:
> Marc Glisse <marc.glisse at inria.fr> writes:
> Indeed they overwrite config.guess with configfsf.guess, which is
> wrong. They are probably doing it so the resulting package is
> portable, but I guess they should use --enable-fat instead (or maybe
> --build=`./configfsf.guess` if they are tight?).
> The latter still is not robust, since we don't make any promises about
> the existence of configfsf.guess. (They could provide their own
> config.guess, stored outside of GMP, though.)
Would it make sense to introduce some option to gmp to do this robustly?
(kind of the reverse of --enable-fat, compile only for the lowest common
base of the category, but still with asm) Maybe not, but that would be a
way to avoid people doing this kind of hack.
I'll advise them to use --enable-fat.
> And they also seem to have CXXFLAGS that override the gmp ones (only
> on Darwin).
> However that doesn't seem to be the only cause of their trouble, at
> least the libtoolize patch is needed there.
> Why is that needed? To me, it seems libtool is not passing the options
> it passes on other darwin systems. Something is causing this non-
> standard behaviour.
The libtoolize thing is not for darwin, it is for places where the
failures look like: "no rule to make target add_n.lo" and are because
recent autoconf is incompatible with ancient ltmain.sh.
Hmm, actually, now I've applied that patch, the CXXFLAGS look correct on
Darwin. I have no idea why but I won't look into it more.
Their Darwin build of the main branch (5.0 works) now fails with:
ld: in mpn/.libs/mod_34lsub1.o, in section __DATA,__data reloc 0:
X86_64_RELOC_SUBTRACTOR must have r_extern=1
which is much more like the usual bugs that get reported :-)
> Please explain why it is important for a public test setup to follow
> documented build instructions:
> (1) Bogus test failures waste time for developers.
> (2) If they tinker and break things, it reflects badly on the package
> developerts, while it should actually reflect badly on the
> (3) Most users are much more likely to follow documented build
> procedures, and thus we would like to make those as resilient as
> possible. (Making it resilient against mindless tinkering is
I'll copy paste :-)
More information about the gmp-devel