Update fplll (and lots of other programs/libraries) #3683
Conversation
|
The tests all passed building fplll (see https://github.com/Macaulay2/M2/actions/runs/13697326897). I'll remove the last commit and make sure that the tests pass when using the Ubuntu/brew packages. |
|
@d-torrance Do we have any other libraries/packages that we sometimes build that are out of date? |
|
Quite possibly! I discovered not too long ago that when we built GMP it was like a 10 year old version. It would definitely be good to go through everything and check. |
|
I audited what we're building (at least on the autotools side of things). These are the things that are out of date:
|
d-torrance
force-pushed
the
fplll
branch
3 times, most recently
from
e6ccd91 to
b72e095
Compare
d-torrance
changed the title
|
@mahrud: I couldn't figure out how to force cmake to build nauty using |
d-torrance
force-pushed
the
fplll
branch
4 times, most recently
from
896ba36 to
f09a9d5
Compare
|
All the tests are finally passing when we build all these libraries and programs! https://github.com/Macaulay2/M2/actions/runs/13733104922 I'll remove the final commit now and go back to Ubuntu/Homebrew packages |
M2/cmake/check-libraries.cmake
Outdated
| @@ -178,7 +178,6 @@ endif() | |||
| ############################################################################### | |||
| ## TODO: Do we still want these libraries? | |||
| # fplll Lattice algorithms using floating-point arithmetic (uses gmp and mpfr) | |||
| # linbox Exact computational linear algebra (needs fflas and givaro) | |||
There was a problem hiding this comment.
My understanding was that Mike was still interested in experimenting with Linbox, even though it isn't actively in use.
There was a problem hiding this comment.
@mikestillman - What's the status of using linbox?
There was a problem hiding this comment.
I did have the plan to experiment with linbox, but I haven't done so recently.
|
This is definitely not in the scope here, but if you're looking at LLL package anyway, would be great if you could:
gramm
gramm(Matrix)
LLL(...,Limit=>...)
gcdLLL(...,Strategy=>...)
kernelLLL
kernelLLL(...,Limit=>...)
kernelLLL(Matrix)
hermite
hermite(Matrix)
hermite(...,Strategy=>...)
hermite(...,ChangeMatrix=>...)
hermite(...,Limit=>...) |
d-torrance
added
waiting for review
build issue
|
Msolve 0.7.5 was just released, so I've updated this PR accordingly. |
|
It really doesn't matter. |
|
Ok cool. I'll keep this PR the same, then. At some point between 1.16 and the current commit, googletest removed support for C++14, which is leading to a failure in the autotools build in RHEL: |
Now checks to see if system library exists rather than always building it.
Also:
- make sure that it's always built as a shared library in
cmake (needed for ForeignFunctions package)
- make sure that gc util program can find gc in macOS
|
@d-torrance Is there anything specific you are worried about here that I should take a look at. In general, upgrading packages, at least when all the tests pass, seems like a great idea...! |
|
@d-torrance Would it be possible to keep the linbox stuff for now? They are doing some work on the program (some commits within the last few months, not huge amount at all), and they do, I believe, handle sparse matrices over finite fields, which maybe we could use... Everything else looks great in this PR... |
|
Ok -- I'll rebase out the linbox commit and then merge |
For some reason, autoreconf isn't overwriting the existing aclocal.m4, so we manually remove it first.
Otherwise, the build fails when LAPACK is a static library (e.g., when built by autotools). Also bump ForeignFunctions to version 0.5
Also: * Remove the requirement that we build a shared bdwgc library in autotools * Update the check for GC_get_full_gc_total_time. ifndef was the wrong thing to use since it's not a macro. We were *always* declaring it, which wasn't a problem unless we were statically linking bdwgc. Then we got redefinition errors. [ci skip]
I'd never noticed this before, but we have the option of linking against fplll to use for one of the
LLLstrategies in theLLLBasespackage. However, we were forced to build it ourselves rather than using the library already available on the system, and the version we were building was over 10 years old!We update the autotools build so that it also checks the system for the library, and so that when we do build it, we build the latest version.
This is a draft for now to make sure that the tests still pass when building fplll ourselves. If that all works, then I'll remove that commit and just use the Ubuntu/brew fplll packages.