Updating configfsf.*

[Marc Glisse]

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
>    tinkerers...
>
> (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
>    futile.)

I'll copy paste :-)

-- 
Marc Glisse