Erik Bray wrote:
> On Thu, Aug 4, 2016 at 11:26 AM, leif <not.rea...@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

> 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


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to