So...who are the Singular experts?

304 views
Skip to first unread message

Erik Bray

unread,
Jul 28, 2016, 10:32:29 AM7/28/16
to sage-devel
...and in particular, are any omalloc experts watching this list?

I ask because my current issue in the Cygwin port of Sage is a
segfault that's occurring in Singular during a routine memory
deallocation of GMP integers.

I'm working on getting a Singular compiled without omalloc to see if
that makes any difference. In the meantime I just thought I'd reach
out to see what expertise I have to draw on in the community.

Thanks,
Erik

Jean-Pierre Flori

unread,
Jul 28, 2016, 10:39:54 AM7/28/16
to sage-devel
Is it with Singular 3?
We should head toward Singular 4.
See https://trac.sagemath.org/ticket/17254
I don't have much time this days but a very annoying bug was recently tracked down (and needs upstream fixing).

Jan Groenewald

unread,
Jul 28, 2016, 10:40:04 AM7/28/16
to sage-devel
Hi




You can also ask here : https://mail.mathematik.uni-kl.de/mailman/listinfo/singular
who might redirect you to a contact person or one of the singular developers.

Regards,
Jan


--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^ 

Jean-Pierre Flori

unread,
Jul 28, 2016, 10:53:22 AM7/28/16
to sage-devel

Jean-Pierre Flori

unread,
Jul 28, 2016, 10:54:42 AM7/28/16
to sage-devel
And at some point I had to disable omGetBackTrace: https://trac.sagemath.org/ticket/15679

leif

unread,
Jul 28, 2016, 11:29:13 AM7/28/16
to sage-...@googlegroups.com
Jean-Pierre Flori wrote:
> And at some point I had to disable omGetBackTrace:
> https://trac.sagemath.org/ticket/15679

IIRC there's also some OM_DEBUG (or OM_NDEBUG?) preprocessor constant
you could toggle. (Perhaps it's even a debug /level/.)

Btw., you're not using GCC 6.1 (with some previous beta of Sage) on
Cygwin yet, I guess. Otherwise some trouble could come from that, too.


-leif


Nils Bruin

unread,
Jul 28, 2016, 11:52:43 AM7/28/16
to sage-devel


On Thursday, July 28, 2016 at 8:29:13 AM UTC-7, leif wrote:
Jean-Pierre Flori wrote:
> And at some point I had to disable omGetBackTrace:
> https://trac.sagemath.org/ticket/15679

IIRC there's also some OM_DEBUG (or OM_NDEBUG?) preprocessor constant
you could toggle.  (Perhaps it's even a debug /level/.)

See also

https://trac.sagemath.org/ticket/13731

for some hints on memory debugging in singular. At one point we succeeded in building singular with "xalloc" rather than "omalloc", which has the advantage that normal memory debugging tools (such a valgrind, electric fence, etc.) work for it.

With a little luck you can get all this by just setting SAGE_DEBUG=yes when you build singular, but I'd expect that it has bitrotted by now and would need some loving attention to get it working again.

Jean-Pierre Flori

unread,
Jul 28, 2016, 12:10:48 PM7/28/16
to sage-devel


On Thursday, July 28, 2016 at 5:52:43 PM UTC+2, Nils Bruin wrote:

With a little luck you can get all this by just setting SAGE_DEBUG=yes when you build singular, but I'd expect that it has bitrotted by now and would need some loving attention to get it working again.
I think it still worked one year ago! even on Cygwin.

leif

unread,
Jul 28, 2016, 12:31:39 PM7/28/16
to sage-...@googlegroups.com
Last time I tried on Linux (perhaps one or two weeks ago) it
embarrassingly failed...

(Didn't look closer into the issue though, but IIRC some symbols needed
by a couple of modules weren't defined.)


-leif


Volker Braun

unread,
Jul 28, 2016, 1:46:58 PM7/28/16
to sage-devel
One of the buildbots is building with SAGE_DEBUG=yes


On Thursday, July 28, 2016 at 5:52:43 PM UTC+2, Nils Bruin wrote:

Erik Bray

unread,
Jul 28, 2016, 2:03:16 PM7/28/16
to sage-devel
Thanks everyone for all the tips. I'm heading out for vacation again
but will be back in a week and will go through them one by one.

For what it's worth I think I'm close in on the problem:

The way Singular is being built and/or how DLLs are being loaded it's
ending up with both GMP and MPIR simultaneously, and this causes a
great deal of confusion, not the least of which that
mp_set_memory_functions is being called in one but not the other.

The end result is a segfault on a memory address that was allocated
with the system allocator, but is being freed by omalloc.

Not sure why this is happening but it must be a build issue.

Erik Bray

unread,
Jul 28, 2016, 2:10:20 PM7/28/16
to sage-devel
I just completed a build of Singular where I had forcibly changed all
instances of -lgmp to -lmpir in the makefiles, and it works now, so
that's reassuring.

leif

unread,
Jul 28, 2016, 3:43:03 PM7/28/16
to sage-...@googlegroups.com
When you're back, you could try building Sage with the optional GMP
package*. I'm curious as to whether you'll then get two instances of
GMP... ;-)

(The optional package is still at 5.1.3 IIRC though, but until then I'll
perhaps have upgraded it to GMP 6.1.1.)


Have fun,

-leif

___________________________
* ./configure --with-mp=gmp


Simon King

unread,
Jul 28, 2016, 4:59:20 PM7/28/16
to sage-...@googlegroups.com
Hi Eric,

On 2016-07-28, Erik Bray <erik....@gmail.com> wrote:
> ...and in particular, are any omalloc experts watching this list?
>
> I ask because my current issue in the Cygwin port of Sage is a
> segfault that's occurring in Singular during a routine memory
> deallocation of GMP integers.

The singular-spkg can be built in debug mode (IIRC, one has to export
SAGE_DEBUG=yes before doing make). And if I recall correctly, it isn't
using omalloc in this debug mode, so that classical debuggers will have
a chance to work.

Hence, I suggest building it in debug mode and see whether you can
detect an upstream bug in the deallocation.

Best regards,
Simon

leif

unread,
Jul 30, 2016, 2:26:14 PM7/30/16
to sage-...@googlegroups.com
Just be warned: Building Sage with its GMP package appears to be broken.

First of all, it's not sufficient to reconfigure with --with-mp=gmp and
rerun 'make' (which was, AFAIK, supposed to or intended to work).

Running 'make build-clean' and then reconfiguring doesn't work either;
presumably that doesn't rebuild everything that it should. (Gave
hundreds of crashes and timeouts in ptestlong IIRC, among them glibc
detected invalid free()s and realloc()s of python.)

Deleting local/var/lib/sage/installed/* in advance "worked", but gave
trouble in the build (e.g. gf2x's tuning consistently failed with an
assertion error). With GCC 6.1. at least, the build finally succeeded
(is installing sagetex-3.0 with SAGE_CHECK=yes supposed to work?), but
docbuilding got stuck, leaving 1 to N (-jN) python processes, 1 or N-1
running 100% without any progress even after hours. (I also retried a
couple of times.)

On a similar system, I did build Sage 7.3.rc0 with SAGE_INSTALL_GCC=yes
and --with-mp=gmp from scratch, which led to a couple of doctest errors,
most of them "harmless" I think, but also crashes in e.g. libsingular.


-leif


leif

unread,
Jul 30, 2016, 6:14:12 PM7/30/16
to sage-...@googlegroups.com
To not hijack Erik's original thread on GMP/MPIR-related issues with
/Singular on Cygwin/, this is a follow-up concerning just building Sage
with its GMP package (instead of MPIR, which is the default).

Sage's optional gmp package is currently GMP 5.1.3 (i.e., quite old).
Back on the other system, I did the same (again), this time with GCC 5.4.
Now the build went smooth except for GSL's testsuite now failing
(something I've seen in the past on other systems as well); sagetex's
testsuite in contrast now passed, tuning gf2x also worked, and
docbuilding succeeded without any issues.

But in ptestlong I'm getting the same (I think) failures as on the other
machine (where I built with Sage's GCC, 4.9.3):

----------------------------------------------------------------------
sage -t --long src/doc/en/constructions/algebraic_geometry.rst # 1
doctest failed
sage -t --long src/doc/en/developer/coding_in_other.rst # 1 doctest failed
sage -t --long src/sage/ext/memory.pyx # 1 doctest failed
sage -t --long src/sage/matrix/matrix_double_dense.pyx # 1 doctest failed
sage -t --long src/sage/libs/gap/assigned_names.py # 1 doctest failed
sage -t --long src/sage/rings/integer.pyx # 1 doctest failed
sage -t --long src/sage/structure/sage_object.pyx # Killed due to abort
----------------------------------------------------------------------

(Ignore the fourth and 5th errors; the former is [still] due to numeric
noise, the latter *always* fails on first try, passes when rerun.)

Some may be known issues ("harmless" doctest failures but also more
severe ones); the comments on the ticket upgrading the optional GMP
package to 5.1.3 [1] and its follow-up [2] aren't all that clear to me,
especially regarding the outcome when the ticket(s) got merged.


-leif


[1] https://trac.sagemath.org/ticket/12661

[2] https://trac.sagemath.org/ticket/15957

leif

unread,
Jul 30, 2016, 6:32:52 PM7/30/16
to sage-...@googlegroups.com

leif

unread,
Jul 30, 2016, 6:37:14 PM7/30/16
to sage-...@googlegroups.com

leif

unread,
Jul 30, 2016, 6:40:56 PM7/30/16
to sage-...@googlegroups.com
leif wrote:
> To not hijack Erik's original thread on GMP/MPIR-related issues with
> /Singular on Cygwin/, ...

Sorry, took me three attempts to detach the post.


-leif


Francois Bissey

unread,
Jul 30, 2016, 6:54:18 PM7/30/16
to sage-...@googlegroups.com
sage-on-gentoo builds with gmp instead of mpir. There are a few doctests
failing as a consequence but sage works. In fact the last ecl upgrade
I pushed was partly to remove noise as I had to upgrade ecl in
sage-on-gentoo to deal with some gmp/ecl issues. Currently I have gmp 6.1.1.

The failing doctests are
sage -t --long /usr/lib64/python2.7/site-packages/sage/libs/libecm.pyx # 1 doctest failed
I had an interesting discussion wit Paul Zimmerman of gmp-ecm and I think
the doctest should be changed for that case.
sage -t --long /usr/lib64/python2.7/site-packages/sage/rings/integer.pyx # 1 doctest failed
sage -t --long /usr/lib64/python2.7/site-packages/sage/ext/memory.pyx # 1 doctest failed
gmp and mpir report errors differently. There is not much we can do for these two but they
are not about mathematical output.

François
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

leif

unread,
Jul 30, 2016, 7:39:32 PM7/30/16
to sage-...@googlegroups.com
(Quoted message copied from wrong/original thread.)

Francois Bissey wrote:
> sage-on-gentoo builds with gmp instead of mpir. There are a few doctests
> failing as a consequence but sage works. In fact the last ecl upgrade
> I pushed was partly to remove noise as I had to upgrade ecl in
> sage-on-gentoo to deal with some gmp/ecl issues. Currently I have gmp
6.1.1..

Currently retrying with GMP 6.1.1 (and GCC 5.4), too; I'll presumably
open a ticket to upgrade Sage's GMP package.


> The failing doctests are
> sage -t --long /usr/lib64/python2.7/site-packages/sage/libs/libecm.pyx
# 1 doctest failed
> I had an interesting discussion wit Paul Zimmerman of gmp-ecm and I think
> the doctest should be changed for that case.

I'll see...


> sage -t --long
/usr/lib64/python2.7/site-packages/sage/rings/integer.pyx # 1 doctest
failed
> sage -t --long /usr/lib64/python2.7/site-packages/sage/ext/memory.pyx
# 1 doctest failed
> gmp and mpir report errors differently. There is not much we can do
for these two but they
> are not about mathematical output.

Hmmm, I *think* we can mark them '# optional -- mpir' (and add modified
copies with '# optional -- gmp').


-leif


leif

unread,
Jul 31, 2016, 2:55:08 AM7/31/16
to sage-...@googlegroups.com
This is what I get with GMP 6.1.1 (Sage 7.3.rc0, GCC 5.4.0):

----------------------------------------------------------------------
sage -t --long --warn-long 68.2 src/sage/structure/sage_object.pyx #
Killed due to abort
sage -t --long --warn-long 68.2 src/sage/rings/integer.pyx # 1 doctest
failed
sage -t --long --warn-long 68.2 src/sage/homology/simplicial_complex.py
# 1 doctest failed
sage -t --long --warn-long 68.2 src/doc/en/developer/coding_in_other.rst
# 1 doctest failed
sage -t --long --warn-long 68.2
src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
sage -t --long --warn-long 68.2 src/sage/matrix/matrix_double_dense.pyx
# 1 doctest failed
sage -t --long --warn-long 68.2 src/sage/libs/libecm.pyx # 1 doctest failed
sage -t --long --warn-long 68.2 src/sage/ext/memory.pyx # 1 doctest failed
----------------------------------------------------------------------

(Haven't tried to change any doctests yet. Again, the failure in
src/sage/matrix/matrix_double_dense.pyx is just the usual numeric noise,
cf. #21119.)


The backtraces for src/sage/structure/sage_object.pyx are horribly long,
but in the stack backtrace there is:


#6 0x00007f7861f7c390 in abort () from /lib/libc.so.6
No symbol table info available.
#7 0x00007f7854dfa84b in NTL::TerminalError (s=s@entry=0x7f7854e24a1f
"InvMod: inverse undefined") at tools.c:25
No locals.
#8 0x00007f7854d106a6 in InvModError (msg=0x7f7854e24a1f "InvMod:
inverse undefined") at ../include/NTL/tools.h:558
No locals.
#9 NTL::InvMod (a=<optimized out>, n=244) at ZZ.c:353


and we have:


Cython backtrace
----------------
#0 0x00007f7862967430 in waitpid()
#1 0x00007f785dec5eb0 in print_enhanced_backtrace()at
/tmp/sage-build-tmp/cysignals-1.1.1/src/build/src/cysignals/implementation.c:401
#2 0x00007f785dec6680 in sigdie()at
/tmp/sage-build-tmp/cysignals-1.1.1/src/build/src/cysignals/implementation.c:420
#3 0x00007f785dec8f70 in cysigs_signal_handler()at
/tmp/sage-build-tmp/cysignals-1.1.1/src/build/src/cysignals/implementation.c:204
#4 0x00007f78629678f0 in __restore_rt()
#5 0x00007f7862967790 in raise()
#6 0x00007f7861f7c210 in abort()
#7 0x00007f7854dfa820 in NTL::TerminalError()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/tools.c:25
#8 0x00007f7854d1069a in InvModError()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/../include/NTL/tools.h:558
#9 0x00007f7854da1870 in NTL::InvMod()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/ZZ.c:353
#10 0x00007f7854da3136 in inv()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/../include/NTL/lzz_p.h:357
#11 0x00007f7854da30d0 in NTL::PlainRem()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/lzz_pX.c:1061
#12 0x00007f7854da6530 in NTL::rem()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/lzz_pX.c:3236
#13 0x00007f7854db1990 in NTL::GCD()at
/tmp/sage-build-tmp/ntl-9.8.1.p1/src/ntl/src/lzz_pX1.c:561
#14 0x00007f72791f27c7 in GCD()at
/data/Sage/release/devel/sage-7.3.rc0-gcc-5.4-gmp-6.1.1/local/include/NTL/lzz_pX.h:743
738
739 void GCD(zz_pX& x, const zz_pX& a, const zz_pX& b);
740 // x = GCD(a, b), x is always monic (or zero if a==b==0).
741
742 inline zz_pX GCD(const zz_pX& a, const zz_pX& b)
> 743 { zz_pX x; GCD(x, a, b); NTL_OPT_RETURN(zz_pX, x); }
744
745
746 void XGCD(zz_pX& d, zz_pX& s, zz_pX& t, const zz_pX& a, const
zz_pX& b);
747 // d = gcd(a,b), a s + b t = d
#15 0x00007f72791f2737 in gcd_univar_ntlp()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:1131
#16 0x00007f72791f1cb0 in gcd_poly_p()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:674
#17 0x00007f72791f1a70 in gcd_poly()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:869
#18 0x00007f72791f3340 in gcd()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:1065
#19 0x00007f72791f56f0 in cf_content()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:911
#20 0x00007f785d9a7a10 in content()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:964
#21 0x00007f785d9a7a10 in content()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:968
#22 0x00007f727921f170 in EZGCD_P()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd_smallp.cc:4261
#23 0x00007f72791f1a70 in gcd_poly()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:855
#24 0x00007f72791f5bf0 in chinrem_gcd()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:1334
#25 0x00007f72791f1a70 in gcd_poly()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:876
#26 0x00007f72791f3340 in gcd()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/factory/cf_gcd.cc:1065
#27 0x00007f727906e6e0 in singclap_gcd_r()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/kernel/clapsing.cc:53
#28 0x00007f727906eab0 in singclap_gcd()at
/tmp/sage-build-tmp/singular-3.1.7p1.p1/src/latest/kernel/clapsing.cc:106
#29 0x00007f727865e2c0 in
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular_106gcd()at
/data/Sage/release/devel/sage-7.3.rc0-gcc-5.4-gmp-6.1.1/src/build/cythonized/sage/rings/polynomial/multi_polynomial_libsingular.cpp:36959
36954 * if _ring!=currRing: rChangeCurrRing(_ring) #
singclap_gcd
36955 * _res = singclap_gcd(p_Copy(self._poly, _ring),
p_Copy(_right._poly, _ring)) # <<<<<<<<<<<<<<
36956 * if count >= 20:
36957 * sig_off()
36958 */
> 36959 __pyx_v__res = singclap_gcd(p_Copy(__pyx_v_self->_poly,
__pyx_v__ring), p_Copy(__pyx_v__right->_poly, __pyx_v__ring));
36960
36961 /*
"sage/rings/polynomial/multi_polynomial_libsingular.pyx":4600
36962 * if _ring!=currRing: rChangeCurrRing(_ring) #
singclap_gcd
36963 * _res = singclap_gcd(p_Copy(self._poly, _ring),
p_Copy(_right._poly, _ring))
...


so libsingular calls NTL with some crap...


-leif


leif

unread,
Jul 31, 2016, 3:34:23 AM7/31/16
to sage-...@googlegroups.com
leif wrote:
> Francois Bissey wrote:
>> The failing doctests are
>> sage -t --long
>> /usr/lib64/python2.7/site-packages/sage/rings/integer.pyx # 1 doctest
>> failed
>> sage -t --long /usr/lib64/python2.7/site-packages/sage/ext/memory.pyx
>> # 1 doctest failed
>> gmp and mpir report errors differently. There is not much we can do
>> for these two but they
>> are not about mathematical output.
>
> Hmmm, I *think* we can mark them '# optional -- mpir' (and add modified
> copies with '# optional -- gmp').

Yep, for example the following works:


diff --git a/src/sage/ext/memory.pyx b/src/sage/ext/memory.pyx
index fe8278f..a6114eb 100644
--- a/src/sage/ext/memory.pyx
+++ b/src/sage/ext/memory.pyx
@@ -6,11 +6,16 @@ TESTS:
Check that a ``MemoryError`` is raised if we try to allocate a
ridiculously large integer, see :trac:`15363`::

- sage: 2^(2^63-2)
+ sage: 2^(2^63-2) # optional -- mpir
Traceback (most recent call last):
...
RuntimeError: exponent must be at most 2147483647 # 32-bit
MemoryError: failed to allocate 1152921504606847008 bytes # 64-bit
+ sage: 2^(2^63-2) # optional -- gmp # not tested
+ gmp: overflow in mpz type
+ Traceback (most recent call last):
+ ...
+ RuntimeError: Aborted

AUTHORS:

diff --git a/src/sage/rings/integer.pyx b/src/sage/rings/integer.pyx
index 53f4da4..0d5e701 100644
--- a/src/sage/rings/integer.pyx
+++ b/src/sage/rings/integer.pyx
@@ -6043,11 +6043,16 @@ cdef class
Integer(sage.structure.element.EuclideanDomainElement):

TESTS::

- sage: 1 << (2^60)
+ sage: 1 << (2^60) # optional -- mpir
Traceback (most recent call last):
...
MemoryError: failed to allocate ... bytes # 64-bit
OverflowError: ... # 32-bit
+ sage: 1 << (2^60) # optional -- gmp # not tested
+ gmp: overflow in mpz type
+ Traceback (most recent call last):
+ ...
+ RuntimeError: Aborted
"""
cdef long n


(The '# not tested' in addition is necessary because of the abort() /
RunTimeError. Not sure whether we could catch that on the Cython level,
but AFAIK GMP intentionally bails out on such errors; there's no way to
resume from them as is.)


-leif


Francois Bissey

unread,
Jul 31, 2016, 3:57:46 AM7/31/16
to sage-...@googlegroups.com

> On 31/07/2016, at 18:54, leif <not.r...@online.de> wrote:
>
> This is what I get with GMP 6.1.1 (Sage 7.3.rc0, GCC 5.4.0):
>
> ----------------------------------------------------------------------
> sage -t --long --warn-long 68.2 src/sage/structure/sage_object.pyx #
> Killed due to abort
> sage -t --long --warn-long 68.2 src/sage/rings/integer.pyx # 1 doctest
> failed
> sage -t --long --warn-long 68.2 src/sage/homology/simplicial_complex.py
> # 1 doctest failed
> sage -t --long --warn-long 68.2 src/doc/en/developer/coding_in_other.rst
> # 1 doctest failed
> sage -t --long --warn-long 68.2
> src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
> sage -t --long --warn-long 68.2 src/sage/matrix/matrix_double_dense.pyx
> # 1 doctest failed
> sage -t --long --warn-long 68.2 src/sage/libs/libecm.pyx # 1 doctest failed
> sage -t --long --warn-long 68.2 src/sage/ext/memory.pyx # 1 doctest failed
> ----------------------------------------------------------------------

I’ll assume this is a build from scratch with gmp.
I think coding_in_other.rst and algebraic_geometry.rst
are basically the same kind of errors. I had them for a while
and then they disappeared. The failure is triggered because
the order of the terms in the output is different.
I used to have noise in matrix_double_dense.pyx from openblas
but I patched that.

The rest is new to me. Would have to dig difference between
your ntl/singular and mine at least.

What’s the failure with simplicial_complex.py?

François

Volker Braun

unread,
Jul 31, 2016, 4:04:41 AM7/31/16
to sage-devel

leif

unread,
Jul 31, 2016, 4:32:47 AM7/31/16
to sage-...@googlegroups.com
Francois Bissey wrote:
>
>> On 31/07/2016, at 18:54, leif <not.r...@online.de> wrote:
>>
>> This is what I get with GMP 6.1.1 (Sage 7.3.rc0, GCC 5.4.0):
>>
>> ----------------------------------------------------------------------
>> sage -t --long --warn-long 68.2 src/sage/structure/sage_object.pyx #
>> Killed due to abort
>> sage -t --long --warn-long 68.2 src/sage/rings/integer.pyx # 1 doctest
>> failed
>> sage -t --long --warn-long 68.2 src/sage/homology/simplicial_complex.py
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/doc/en/developer/coding_in_other.rst
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2
>> src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/matrix/matrix_double_dense.pyx
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/libs/libecm.pyx # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/ext/memory.pyx # 1 doctest failed
>> ----------------------------------------------------------------------
>
> I’ll assume this is a build from scratch with gmp.

Yes. I replaced the optional GMP package, i.e., upgraded it to 6.1.1.


> I think coding_in_other.rst and algebraic_geometry.rst
> are basically the same kind of errors. I had them for a while
> and then they disappeared. The failure is triggered because
> the order of the terms in the output is different.

Yes. But someone should make the doctests more robust w.r.t. this.


> I used to have noise in matrix_double_dense.pyx from openblas
> but I patched that.

A patch for my Haswells has positive review, but isn't merged yet.
(tol changed from 1e-14 to 1.1e-14; see also #21121, a follow-up.)


> The rest is new to me. Would have to dig difference between
> your ntl/singular and mine at least.
>
> What’s the failure with simplicial_complex.py?

Good question. Passed when rerun separately. Digging in ptestlong.log
I found:

sage -t --long --warn-long 68.2 src/sage/homology/simplicial_complex.py
**********************************************************************
File "src/sage/homology/simplicial_complex.py", line 2813, in
sage.homology.simplicial_complex.SimplicialComplex.is_cohen_macaulay
Failed example:
X.is_cohen_macaulay(ZZ)
Expected:
False
Got:
[Errno 2] No such file or directory:
'/home/leif/.sage/temp/tunguska/16183/dir_5o8pnH/16223.out'
False
**********************************************************************

So apparently not related to GMP, just another flaky test. (Although I
don't recall having seen that before.)


-leif


leif

unread,
Jul 31, 2016, 5:49:37 PM7/31/16
to sage-...@googlegroups.com
leif wrote:
> leif wrote:
>> Currently retrying with GMP 6.1.1 (and GCC 5.4), too; I'll presumably
>> open a ticket to upgrade Sage's GMP package.
>>
>>
>>> The failing doctests are
>>> [...]
I've now also added


diff --git a/src/sage/structure/sage_object.pyx
b/src/sage/structure/sage_object.pyx
index 5b79052..e187b03 100644
--- a/src/sage/structure/sage_object.pyx
+++ b/src/sage/structure/sage_object.pyx
@@ -1498,9 +1498,11 @@ def unpickle_all(dir = None, debug=False,
run_test_suite=False):

Check that unpickling a second time works (see :trac:`5838`)::

- sage: sage.structure.sage_object.unpickle_all()
+ sage: sage.structure.sage_object.unpickle_all() # optional -- mpir
Successfully unpickled ... objects.
Failed to unpickle 0 objects.
+ sage: sage.structure.sage_object.unpickle_all() # optional --
gmp # known bug
+ ...

When it is not possible to unpickle a pickle in the pickle_jar then
:meth:`unpickle_all` prints the following error message which warns
against removing


because this is an old bug (happened in the past with MPIR as well)
which never got fixed nor really tracked down, just the now failing
doctest (unpickling all a second time) got added in #5838; I've also
commented there [1].


-leif

[1] https://trac.sagemath.org/ticket/5838#comment:25
> ....

François Bissey

unread,
Jul 31, 2016, 6:00:44 PM7/31/16
to sage-...@googlegroups.com
On 01/08/16 09:49, leif wrote:
> because this is an old bug (happened in the past with MPIR as well)
> which never got fixed nor really tracked down, just the now failing
> doctest (unpickling all a second time) got added in #5838; I've also
> commented there [1].
>
>
> -leif
>
> [1] https://trac.sagemath.org/ticket/5838#comment:25

The few times we got unpickling problems in sage-on-gentoo
we tracked it down to underlinking. But I don't think
it was ever this doctest.
Steve Trogdon may remember something.

Francois

Jean-Pierre Flori

unread,
Aug 2, 2016, 5:35:10 AM8/2/16
to sage-devel
I think that I some point I wanted to support switching btw GMP and MPIR and then someone convinced me it was hopeless.
The only supported solution should be to distclean, reconfigure, rebuild.
If that does not work, we should fix it.

As far as error are concerned, I remember that MPIR and GMP behaved differently when more memory than possible was tried to be allocated.
And there were a few other discrepancies in the doctests and we decided to live with it.

Also note that GMP changed its behavior for some gcd or modular reduction computations or something like that btw the 5.x and 6.x series, MPIR did not mimick this behavior yet.

Francois Bissey

unread,
Aug 2, 2016, 5:42:50 AM8/2/16
to sage-...@googlegroups.com
I would have to check my discussions with Paul but I think that’s why there
is a difference for the ecm doctest (with Paul saying that he likes the current
gmp behaviour).

François

leif

unread,
Aug 2, 2016, 2:04:06 PM8/2/16
to sage-...@googlegroups.com
Francois Bissey wrote:
> I would have to check my discussions with Paul but I think that’s why there
> is a difference for the ecm doctest (with Paul saying that he likes the current
> gmp behaviour).

We fixed FLINT w.r.t. this (invertability modulo +/-1) at least, such
that FLINT > 2.4.5 copes with both GMP 5.x and 6.x, so IMHO yes.
(Haven't yet looked at the ECM / libecm extension module doctest though,
so I don't know if it's that, too.)

MPIR will "catch up" with the next major release, some time in the future.


-leif

leif

unread,
Aug 2, 2016, 7:03:49 PM8/2/16
to sage-...@googlegroups.com
leif wrote:
> Francois Bissey wrote:
>> I would have to check my discussions with Paul but I think that’s why there
>> is a difference for the ecm doctest (with Paul saying that he likes the current
>> gmp behaviour).
>
> We fixed FLINT w.r.t. this (invertability modulo +/-1) at least, such
> that FLINT > 2.4.5 copes with both GMP 5.x and 6.x, so IMHO yes.
> (Haven't yet looked at the ECM / libecm extension module doctest though,
> so I don't know if it's that, too.)

Oh (now I did), that's really a nice one.

I'd say it's an upstream bug that whether ECM considers 1 a factor of 1
depends on the underlying library (GMP 5.x or MPIR vs. GMP 6.x).

But the last release of GMP-ECM (6.4.4) dates back nearly three and a
half years... (There was some activity to make a 7.x release years ago,
but probably developers unexpectedly left such that development got stuck.)


> MPIR will "catch up" with the next major release, some time in the future.

So I'll have to make the doctest depend not only on the MP library used
(GMP or MPIR), but also its version...

Or just change the test with GMP upon upgrading the optional package to
6.1.1. And again change it for MPIR as well once we upgrade to some 2.8
or later. (As mentioned, a new major release of MPIR doesn't seem to
happen soon.)

leif

unread,
Aug 2, 2016, 7:15:09 PM8/2/16
to sage-...@googlegroups.com
leif wrote:
> I'd say it's an upstream bug that whether ECM considers 1 a factor of 1
> depends on the underlying library (GMP 5.x or MPIR vs. GMP 6.x).
>
> But the last release of GMP-ECM (6.4.4) dates back nearly three and a
> half years... (There was some activity to make a 7.x release years ago,
> but probably developers unexpectedly left such that development got stuck.)

P.S.: Just noticed there's recent activity again:

Revision 2933 - Directory Listing
Modified Tue May 24 15:28:23 2016 UTC (2 months, 1 week ago) by zimmerma

Tagging r2932 as version 7.0.1

Revision 2901 - Directory Listing
Modified Tue Mar 15 10:49:19 2016 UTC (4 months, 2 weeks ago) by zimmerma

Tagging r2900 as version 7.0

Revision 2440 - Directory Listing
Modified Wed Feb 27 15:28:36 2013 UTC (3 years, 5 months ago) by kruppa

Tagged as release 6.4.4


-leif


Francois Bissey

unread,
Aug 2, 2016, 7:24:34 PM8/2/16
to sage-...@googlegroups.com
https://trac.sagemath.org/ticket/20385
for upgrade to 7.0.
Patches need to be ported to the new version.
If there is 7.1 is our=t lets move to that.

François

leif

unread,
Aug 2, 2016, 8:49:03 PM8/2/16
to sage-...@googlegroups.com
Francois Bissey wrote:
> https://trac.sagemath.org/ticket/20385
> for upgrade to 7.0.
> Patches need to be ported to the new version.

Sage currently only has this poor patch:

commit 1f3e8dc1a1f72f99c8c758c80463138bbef90534
Author: John H. Palmieri <palm...@math.washington.edu>
Date: Thu Sep 24 07:43:14 2015 -0700

trac 19233: change ".align 2^n" to ".p2align n"
in the files x86_64/mulredc*.asm, so that ecm will build with
Xcode 7 and OS X 10.11.

(It modifies dozens of asm files, instead of changing a macro on
*Darwin* / depending on the assembler used -- something that should be
checked in 'configure'.)


Haven't looked into 7.x yet, but there's no issue on GMP-ECM's bug
tracker regarding that.

P.S.: According to [1], Paul merged a slightly better patch fixing that
issue. (IMHO the format of alignment directives to use should still get
figured out by 'configure'.)


-leif

[1] https://trac.sagemath.org/ticket/19233#comment:16


François Bissey

unread,
Aug 2, 2016, 11:49:58 PM8/2/16
to sage-...@googlegroups.com
7.0.3 over there:
https://gforge.inria.fr/frs/?group_id=135
fixes stuff for gcc 5+ and gmp 6.1.0 and ppc64.

Will try on recent OS X to check if that bit is fixed.
I was thinking of another QA problem.

Francois

leif

unread,
Aug 3, 2016, 2:43:38 AM8/3/16
to sage-...@googlegroups.com
François Bissey wrote:
> 7.0.3 over there:
> https://gforge.inria.fr/frs/?group_id=135
> fixes stuff for gcc 5+ and gmp 6.1.0 and ppc64.

See ticket, I pushed a branch (can be reviewed / tested).


-leif

Erik Bray

unread,
Aug 4, 2016, 5:01:29 AM8/4/16
to sage-devel
To be honest I'm not even sure how I ended up with GMP in my Sage
install in the first place. I never did --with-mp=gmp. Or is that
what the --enable-gmpcompat flag to MPIR's configure does? Regardless
the end result is two complete copies of the library (I would have
thought just a symlink from mpir to gmp or something).

Singular links explicitly against "gmp", while many other packages are
linked to "mpir". In the end both are being loaded and some symbols
being resolved to one, while other symbols resolved to the other.
It's very confusing.

Erik Bray

unread,
Aug 4, 2016, 5:07:38 AM8/4/16
to sage-devel
On Sun, Jul 31, 2016 at 12:14 AM, leif <not.r...@online.de> wrote:
> To not hijack Erik's original thread on GMP/MPIR-related issues with
> /Singular on Cygwin/, this is a follow-up concerning just building Sage
> with its GMP package (instead of MPIR, which is the default).
>
> Sage's optional gmp package is currently GMP 5.1.3 (i.e., quite old).

Tangentially related, but it might be nice if GMP/MPIR got the same
treatment that some other packages have been getting, a few at a time,
of using the system version if it's available and current enough.
Really should be done for every package in fact, but that's something
I'm happy to take one at a time, especially for such core packages...

Jean-Pierre Flori

unread,
Aug 4, 2016, 5:10:44 AM8/4/16
to sage-devel
Note that GMP uses a lot of assembly when properly built and is used basically by all other libraries.
Using a prebuilt one without specific assembly is maybe not the best idea.

leif

unread,
Aug 4, 2016, 5:19:09 AM8/4/16
to sage-...@googlegroups.com
Jean-Pierre Flori wrote:
> On Thursday, August 4, 2016 at 11:07:38 AM UTC+2, Erik Bray wrote:
>
> Tangentially related, but it might be nice if GMP/MPIR got the same
> treatment that some other packages have been getting, a few at a time,
> of using the system version if it's available and current enough.
> Really should be done for every package in fact, but that's something
> I'm happy to take one at a time, especially for such core packages....
>
> Note that GMP uses a lot of assembly when properly built and is used
> basically by all other libraries.
> Using a prebuilt one without specific assembly is maybe not the best idea.

The assembly is not a problem, since most distros build GMP with
--enable-fat. But the rest gets compiled with arch and tune generic,
not exploiting any instruction set extensions most CPUs nowadays have.

But we could at least /offer/ the option to build Sage with
--with-[g]mp=system etc.


-leif


John Cremona

unread,
Aug 4, 2016, 5:19:22 AM8/4/16
to SAGE devel
If you build mpir with BINDIR=$HOME/progs/bin then the libraries it
creates are called libgmp not libmpir (so that other code which
expects to use gmp can use mpir without any change). This does cause
confusion.

John

>
> Singular links explicitly against "gmp", while many other packages are
> linked to "mpir". In the end both are being loaded and some symbols
> being resolved to one, while other symbols resolved to the other.
> It's very confusing.
>

leif

unread,
Aug 4, 2016, 5:26:18 AM8/4/16
to sage-...@googlegroups.com
We removed any explicit mention of MPIR ('-lmpir', '#include <mpir.h>')
a while ago, but a few newer packages may indeed recognize MPIR
meanwhile and link to that instead. But I'm not aware of a single one.


-leif


Erik Bray

unread,
Aug 4, 2016, 5:36:02 AM8/4/16
to sage-devel
That's not even necessarily all true. Just because it's the "system"
GMP doesn't mean it hasn't been tuned. By default, no, but most OS's
have instructions for building tuned system installs of MP, BLAS, etc.

Erik Bray

unread,
Aug 4, 2016, 5:37:57 AM8/4/16
to sage-devel
In other words, I may already have my own well-tuned collection of
libraries on my system that I want to use Sage with, and that should
be my choice. This goes for almost all Sage's dependencies (so long
as minimal version requirements are met, etc.).

Jean-Pierre Flori

unread,
Aug 4, 2016, 6:18:58 AM8/4/16
to sage-devel
Sure you can build everything from source on your own rather than using system libs or let Sage build stuff :)
That was not my point, it is good to have an option to use the system libraries, but don't expect everything to be well-tuned then.
I don't think a lot of libs provide a fat option as GMP does.
Nor that a lot of distros really tune the package they build for modern archs (unless they want to make their poor users unhappy).
IIRC at some point Debian provided a bunch of different atlas binaries built for different microarchitecture but that must have been a hell to maintain and is not the case anymore.

Erik Bray

unread,
Aug 4, 2016, 8:07:40 AM8/4/16
to sage-devel
Well, what happens with --enable-gmpcompat, at least on Windows, is
that two separate libraries are built: gmp and mpir. I guess the
former is as close to possible as plain gmp, without any features
added by mpir (in fact the gmp library is a little bit smaller). The
MPIR and GMP DLLs have no dependencies on each other.

I did a fresh build of Singular using the current unmodified spkg and
found that the Singular executable itself was linked with:

-lflint -lmpfr -lmpir -lm -lsingfac -lsingcf -lflint -lmpfr -lntl
-lgmp -lreadline -lpthread -lrt -lm -lomalloc

The repetitious stuff is annoying, but harmless. The harm here is
that there is both -lmpir and -lgmp. The -lmpir in this case comes
from Singular's configure.in where it's added to a variable called
FLINT_LIBS which is included in the linker flags for Singular and
libsingular. I don't know if there's some reason it absolutely must
link with mpir for flint to work, but I doubt it?

Further revealing is

$ dumpbin.exe /IMPORTS local/bin/Singular-3-1-7.exe

Dump of file local/bin/Singular-3-1-7.exe

File Type: EXECUTABLE IMAGE

Section contains the following imports:

cyggmp-16.dll
10091C158 Import Address Table
10091B0C8 Import Name Table
0 time date stamp
0 Index of first forwarder reference

DC __gmpn_get_str
195 __gmpz_addmul
196 __gmpz_addmul_ui
19C __gmpz_cdiv_q
19F __gmpz_cdiv_qr
1C1 __gmpz_fdiv_qr_ui
1E2 __gmpz_init_set_str
224 __gmpz_sqrt
228 __gmpz_submul
237 __gmpz_ui_pow_ui

cygmpir-16.dll
10091C1B0 Import Address Table
10091B120 Import Name Table
0 time date stamp
0 Index of first forwarder reference

45 __gmp_set_memory_functions
48 __gmp_sprintf
5A __gmpf_abs
5B __gmpf_add
...

I don't know exactly in what order the GNU linker is resolving symbols
on Windows, but as you can see it is only using 10 functions from the
GMP library, and the rest from MPIR--notably including
mp_set_memory_functions, which jibes with what I found in debugging.

Further revealing is that one of the few functions that are linked to
GMP is mpz_addmul. From my debugging it was exactly in an mpz_addmul
where the default memory allocator was used for an mpz_t, followed
later by an mpz_clear that used the omalloc free on the same object.

So details of the linker aside, this perfectly explains the behavior I
was seeing. It also explains why when I manually removed all
references to "-lgmp" from the Singular makefiles, I was able to fix
the problem.

Now all that needs to be done is the Singular package needs to be
patched properly to *only* use the appropriate $(MP_LIBRARY) (issues
with Sage's gmp package aside), and never get mixed up like this.

Best,
Erik

leif

unread,
Aug 4, 2016, 9:30:16 AM8/4/16
to sage-...@googlegroups.com
Erik Bray wrote:
> On Thu, Aug 4, 2016 at 11:26 AM, leif <not.r...@online.de> wrote:
>> We removed any explicit mention of MPIR ('-lmpir', '#include <mpir.h>')
>> a while ago, but a few newer packages may indeed recognize MPIR
>> meanwhile and link to that instead. But I'm not aware of a single one.
>
> Well, what happens with --enable-gmpcompat, at least on Windows, is
> that two separate libraries are built: gmp and mpir. I guess the
> former is as close to possible as plain gmp, without any features
> added by mpir (in fact the gmp library is a little bit smaller). The
> MPIR and GMP DLLs have no dependencies on each other.

libgmp is identical to libmpir (likewise, gmp.h to mpir.h),
'--enable-gmpcompat' just creates copies under a different name.

(The shared libraries also carry the same version.)

No idea what's going on on Cygwin, but certainly MPIR's libgmp is not
"more compatible" to GMP's than libmpir is.

At some point these were actually the same files, not sym- but
hardlinked, but neither is supported on Cygwin and I guess that's why we
nowadays have two real copies, which isn't necessary either. (If
'--enable-gmpcompat' is used, in Sage at least *only* gmp.h and
libgmp[xx] should get installed, to avoid exactly what happened below.
If the linker bails out because it cannot find -lmpir, fine, since you
know there's a mistake in specifying libraries. Similar for includes
and the preprocessor.)


> I did a fresh build of Singular using the current unmodified spkg and
> found that the Singular executable itself was linked with:
>
> -lflint -lmpfr -lmpir -lm -lsingfac -lsingcf -lflint -lmpfr -lntl
> -lgmp -lreadline -lpthread -lrt -lm -lomalloc

Ouch.


> The repetitious stuff is annoying, but harmless. The harm here is
> that there is both -lmpir and -lgmp.

Well, not exactly. If -lgmp -lmpir -lm (or -lmpir -lgmp -lm) came last,
there wouldn't be a problem, since all symbols would get resolved from
the same library.


> The -lmpir in this case comes
> from Singular's configure.in where it's added to a variable called
> FLINT_LIBS which is included in the linker flags for Singular and
> libsingular. I don't know if there's some reason it absolutely must
> link with mpir for flint to work, but I doubt it?

There was a time when this was indeed the case (FLINT requiring MPIR),
and Singular using FLINT is relatively new, so presumably someone felt
it was clever to explicitly use -lmpir there (too), which is of course
wrong.


-leif

Erik Bray

unread,
Aug 4, 2016, 9:49:22 AM8/4/16
to sage-devel
On Thu, Aug 4, 2016 at 3:28 PM, leif <not.r...@online.de> wrote:
> Erik Bray wrote:
>> On Thu, Aug 4, 2016 at 11:26 AM, leif <not.r...@online.de> wrote:
>>> We removed any explicit mention of MPIR ('-lmpir', '#include <mpir.h>')
>>> a while ago, but a few newer packages may indeed recognize MPIR
>>> meanwhile and link to that instead. But I'm not aware of a single one.
>>
>> Well, what happens with --enable-gmpcompat, at least on Windows, is
>> that two separate libraries are built: gmp and mpir. I guess the
>> former is as close to possible as plain gmp, without any features
>> added by mpir (in fact the gmp library is a little bit smaller). The
>> MPIR and GMP DLLs have no dependencies on each other.
>
> libgmp is identical to libmpir (likewise, gmp.h to mpir.h),
> '--enable-gmpcompat' just creates copies under a different name.
>
> (The shared libraries also carry the same version.)

You're right. I see now that they are identical. The only difference
I saw was specific to Windows, and was actually only in the size of
the import libs, not the DLLs themselves. The size difference in the
import libs is accounted for in the fact that the import lib mentions
the DLL filename in several places.

So if --enable-cmpcompat is literally just making copies maybe we
should remove that, and replace the copies with a rename, or a
symlink.

> No idea what's going on on Cygwin, but certainly MPIR's libgmp is not
> "more compatible" to GMP's than libmpir is.

See above--there's no significant difference.

> At some point these were actually the same files, not sym- but
> hardlinked, but neither is supported on Cygwin and I guess that's why we
> nowadays have two real copies, which isn't necessary either. (If
> '--enable-gmpcompat' is used, in Sage at least *only* gmp.h and
> libgmp[xx] should get installed, to avoid exactly what happened below.
> If the linker bails out because it cannot find -lmpir, fine, since you
> know there's a mistake in specifying libraries. Similar for includes
> and the preprocessor.)
>
>
>> I did a fresh build of Singular using the current unmodified spkg and
>> found that the Singular executable itself was linked with:
>>
>> -lflint -lmpfr -lmpir -lm -lsingfac -lsingcf -lflint -lmpfr -lntl
>> -lgmp -lreadline -lpthread -lrt -lm -lomalloc
>
> Ouch.
>
>
>> The repetitious stuff is annoying, but harmless. The harm here is
>> that there is both -lmpir and -lgmp.
>
> Well, not exactly. If -lgmp -lmpir -lm (or -lmpir -lgmp -lm) came last,
> there wouldn't be a problem, since all symbols would get resolved from
> the same library.

Well sure. I haven't been able to trace exactly why a handful of
symbols are resolved to -lgmp first, and cleaning that mess up might
clarify matters. On Linux though it doesn't seem to be a
problem--everything is found through -lmpir.

>> The -lmpir in this case comes
>> from Singular's configure.in where it's added to a variable called
>> FLINT_LIBS which is included in the linker flags for Singular and
>> libsingular. I don't know if there's some reason it absolutely must
>> link with mpir for flint to work, but I doubt it?
>
> There was a time when this was indeed the case (FLINT requiring MPIR),
> and Singular using FLINT is relatively new, so presumably someone felt
> it was clever to explicitly use -lmpir there (too), which is of course

I added a patch to remove this and it seems to have fixed everything.
I'll create a ticket with the patch. Thanks for reading!

leif

unread,
Aug 4, 2016, 10:56:25 AM8/4/16
to sage-...@googlegroups.com
Erik Bray wrote:
> On Thu, Aug 4, 2016 at 3:28 PM, leif <not.r...@online.de> wrote:
>> Erik Bray wrote:
>>> On Thu, Aug 4, 2016 at 11:26 AM, leif <not.r...@online.de> wrote:
>>>> We removed any explicit mention of MPIR ('-lmpir', '#include <mpir.h>')
>>>> a while ago, but a few newer packages may indeed recognize MPIR
>>>> meanwhile and link to that instead. But I'm not aware of a single one.
>>>
>>> Well, what happens with --enable-gmpcompat, at least on Windows, is
>>> that two separate libraries are built: gmp and mpir. I guess the
>>> former is as close to possible as plain gmp, without any features
>>> added by mpir (in fact the gmp library is a little bit smaller). The
>>> MPIR and GMP DLLs have no dependencies on each other.
>>
>> libgmp is identical to libmpir (likewise, gmp.h to mpir.h),
>> '--enable-gmpcompat' just creates copies under a different name.
>>
>> (The shared libraries also carry the same version.)

Just for the record, that's not 100% true.

The .so versions are the same, but the sonames indeed differ, so we in
fact have two slightly different shared libraries on ELF systems (and
presumably also Darwin), but the symbols and the code are exactly the same.
That's because the GNU linker acts (on some systems still) in a
non-standard way, in that it remembers what symbol definitions it had
already seen; a couple of distros have disabled this behaviour since a
while, others keep it.

E.g. normally 'cc -o foo -lm foo.o' doesn't work if foo.o uses libm,
while it for a long time worked with any GNU ld.


>>> The -lmpir in this case comes
>>> from Singular's configure.in where it's added to a variable called
>>> FLINT_LIBS which is included in the linker flags for Singular and
>>> libsingular. I don't know if there's some reason it absolutely must
>>> link with mpir for flint to work, but I doubt it?
>>
>> There was a time when this was indeed the case (FLINT requiring MPIR),
>> and Singular using FLINT is relatively new, so presumably someone felt
>> it was clever to explicitly use -lmpir there (too), which is of course
>
> I added a patch to remove this and it seems to have fixed everything.
> I'll create a ticket with the patch. Thanks for reading!

Thanks for tracking this down.


-leif


leif

unread,
Aug 5, 2016, 3:18:29 AM8/5/16
to sage-...@googlegroups.com
This apparently is specific to (Singular on) Cygwin, as otherwise my
builds from scratch with --with-mp=gmp would have failed with a linker
error (-lmpir: not found). I also have no traces of mpir in the
Singular package's build log.

CC me when you open a ticket; I'll presumably open one for changing what
the MPIR package installs (with --enable-gmpcompat, which is of course
the default in Sage).


-leif


leif

unread,
Aug 5, 2016, 4:01:47 AM8/5/16
to sage-...@googlegroups.com
I've opened #21174 [1] for the latter.


-leif

[1] https://trac.sagemath.org/ticket/21174


leif

unread,
Aug 9, 2016, 12:29:04 PM8/9/16
to sage-...@googlegroups.com
Francois Bissey wrote:
>
>> On 31/07/2016, at 18:54, leif <not.r...@online.de> wrote:
>>
>> This is what I get with GMP 6.1.1 (Sage 7.3.rc0, GCC 5.4.0):
>>
>> ----------------------------------------------------------------------
>> sage -t --long --warn-long 68.2 src/sage/structure/sage_object.pyx #
>> Killed due to abort
>> sage -t --long --warn-long 68.2 src/sage/rings/integer.pyx # 1 doctest
>> failed
>> sage -t --long --warn-long 68.2 src/sage/homology/simplicial_complex.py
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/doc/en/developer/coding_in_other.rst
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2
>> src/doc/en/constructions/algebraic_geometry.rst # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/matrix/matrix_double_dense.pyx
>> # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/libs/libecm.pyx # 1 doctest failed
>> sage -t --long --warn-long 68.2 src/sage/ext/memory.pyx # 1 doctest failed
>> ----------------------------------------------------------------------
>
> I’ll assume this is a build from scratch with gmp.
> I think coding_in_other.rst and algebraic_geometry.rst
> are basically the same kind of errors. I had them for a while
> and then they disappeared. The failure is triggered because
> the order of the terms in the output is different.

Yes... But not caused by GMP, but by Singular not using FLINT when
(only) libgmp (not in addition libmpir) is installed (cf. #21188).


> [...]
>
> The rest is new to me. Would have to dig difference between
> your ntl/singular and mine at least.

The crash in sage_object.pyx (in unpickle_all(), NTL aborting because a
modular inverse doesn't exist) also vanishes when Singular / libsingular
again uses FLINT, cf. #5838.


-leif


leif

unread,
Aug 9, 2016, 1:56:47 PM8/9/16
to sage-...@googlegroups.com
P.S.: Just checked:

These three doctests fail in exactly the same way when building Sage
with MPIR and configuring Singular --without-flint.


-leif


Reply all
Reply to author
Forward
0 new messages