Update fplll (and lots of other programs/libraries) #3683
Conversation
Now checks to see if system library exists rather than always building it.
|
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/build-libraries.cmake
Outdated
| @@ -180,7 +180,7 @@ ExternalProject_Add(build-bdwgc | |||
| CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${M2_HOST_PREFIX} | |||
| -DCMAKE_SYSTEM_PREFIX_PATH=${M2_HOST_PREFIX} | |||
| -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} | |||
| -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS} | |||
| -DBUILD_SHARED_LIBS=ON # for ForeignFunctions package | |||
There was a problem hiding this comment.
ForeignFunctions has a getMemory function for allocating memory, which is very useful when your foreign function has a pointer as one of its arguments. Under the hood, it calls either GC_malloc or GC_malloc_atomic. Currently, this is implemented as a foreign function at top level, which means that we need libgc to be dynamically linked so we can use dlsym.
It could be implemented differently to allow for static linking by moving some of that code to ffi.d. Would that be preferable?
There was a problem hiding this comment.
I think so? The ability to have a completely static build is always good (though there are currently a few obstacles using the CMake build that I don't understand).
There was a problem hiding this comment.
Updated!
Something is weird when building bdwgc and linking statically in the cmake build on my system, though. M2 is sluggish, we eventually get lots of GC finalization warnings, and the ForeignFunctions tests just segfault. It's not a problem with the autotools build -- I'm not sure what's different.
There was a problem hiding this comment.
FWIW, I checked and I have the same problems statically linking bdwgc in the cmake build on the development branch, so it's not an issue with the newer version of bdwgc or anything.
| @@ -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?
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
|
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
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.
|
Msolve 0.7.5 was just released, so I've updated this PR accordingly. |
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.