On Thu, Aug 4, 2016 at 3:28 PM, leif <not.rea...@online.de> wrote:
> 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.)
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!
--
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.
