Updating configfsf.*

Torbjorn Granlund tg at gmplib.org
Tue May 3 22:43:44 CEST 2011

Marc Glisse <marc.glisse at inria.fr> writes:

  > 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?

Is there a compelling reason for that?

  (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.
Good idea.  It will be great to have all x86 assembly code tested on
Darwin.  :-(

  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.
Ah, they use a much newer autoconf than we have in ~gmp/usr/bin on

  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.
One should be humbly grateful when things mysteriously just work.  :-)

  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 :-)
Yep, welcome to the Darwin linker...  http://gmplib.org/macos.html

So this used to work, but magically broke?  I bet it is the jumptab used
in mpn/x86_64/mod_34lsub1.asm that triggers some bug.  But it has not
changed for about 5 months...

Perhaps subtracting .rodata and .text symbols isn't entirely kosher (see
L(tab) in the file).  If I understand the pedagogical error message
right, they want some of these symbols to be exported.

Perhaps sticking this inside the file will help?  :-)

	.export L(tab)')


More information about the gmp-devel mailing list