Help stabilising mini-gmp

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  If it happens again, the seed should be printed out.
  https://gmplib.org/repo/gmp/rev/5abbd164e2a3
  
Yep.  Unless the smaller operands affects the behaviour.

  > #15 is strange, I haven't tried to understand why these libgcc link
  > errors happens for just certain similar configs.
  
  The direct links to examples are dead.

They were quite garbled, now hopefully fixed.

  Do these system normally have
  LD_LIBRARY_PATH set? If so, maybe something wrong when gmp:s .lib is
  prepended to the path.
  
echo $LD_LIBRARY_PATH 
/usr/local/lib

What confused me was that the -fake test variant (which runs through
many CPUs for a fat build) didn't fail.  Now I see why; they don't
include mini-gmp.

I havn't followed the logic of the local test wrapper, but presumably it
doesn't prepend (or append) correctly to LD_LIBRARY_PATH.

  When the dust has settled, we'll have to think about whether we should
  make a "mini-gmp release" with bug-fixes, or just send out an
  announcement.
  
Agreed.

Let's follow this plan:

1. Fix any issues remaining which we think are are worth fixing (i.e.,
   we don't need to work around every bug elsewhere).

2. Make sure the testsuite is up to scratch wrt hard-to-test algorithms
   (for example those I mentioned yesterday)

3. Then let the test machinery run for a few weeks; this ought to
   trigger any remaining arithmetic bugs.  (Please recall that 6 days
   are required for a full cycle as things are set up these days.)

4. Perhaps release 6.1.2 with the now hopefully bug-free mini-gmp.  (Or
   somehow release it separately (whatever that means) or just shout
   about this and direct people to the repo.)

-- 
Torbjörn
Please encrypt, key id 0xC8601622