Opened 4 years ago
Last modified 2 years ago
#26249 new task
port Sage to FreeBSD 12
Reported by:  dimpase  Owned by:  

Priority:  major  Milestone:  sagepending 
Component:  porting: BSD  Keywords:  
Cc:  mkoeppe  Merged in:  
Authors:  Dima Pasechnik, LiWen Hsu  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  Commit:  
Dependencies:  #26253, #27764  Stopgaps: 
Description (last modified by )
In FreeBSD 12 the longstanding incompleteness of its libm has been helped. This simplifies a lot, compared to #22679.
We will not try to work around the toolchain problem related to gfortran/libgcc_s. Instead, we just add a line at the end of /etc/libmap.conf
as
follows:
libgcc_s.so.1 /usr/local/lib/gcc7/libgcc_s.so.1
Also, we create the following symbolic links:
$ ls l ~/bin total 0 lrwxrxrx 1 dima dima 20 Apr 27 12:49 make > /usr/local/bin/gmake lrwxrxrx 1 dima dima 21 Apr 27 13:46 patch > /usr/local/bin/gpatch
and use the standard shell, /bin/sh
. In ~/.profile
we put
export LDFLAGS="L/usr/local/lib" export CFLAGS="I/usr/local/include" export CXXFLAGS=$CFLAGS export CPPFLAGS=$CFLAGS export FCFLAGS=$CFLAGS export FFLAGS=$CFLAGS
to account for clang not looking into /usr/local
by default.
Things to fix:
 #26250 (fixes to rubiks)
 #27764 (a fix to flint)
 #26253 (update of psutils)
 yasm check is broken on FreeBSD (it's always YES!)
 #26602 (cephes removed)
 #26287 (update to gc, to the FreeBSD's version)
 #26288 (update to matplotlib, fixes compilation errors)
 #26190 (update to latte_intwhich is an optional package)
 #26733 (update to openblas)
 #26315 (update to giac, to be able to use clang 6.0.1)
 #27262 (needed to link
sagelib
to libs from /usr/local/lib)
There is some hope that the libgcc_s.so.1
problem will finally be [fixed in FreeBSD https://lists.freebsd.org/pipermail/freebsdports/2019April/115972.html]
The strategy which would pay off to make Sage an "easy" FreeBSD port is to add/enhance as many needed by Sage external libraries as separate ports into FreeBSD, so that Sage does not need to vendor this. To this end, #27330 is very relevant ticket.
A first foray into this is enhancing FreeBSD's port of flint2 to be linkable with NTL (something that is a requirement for flint2 in Sage), see here. The necessary work on the flint2 side has been done in the meantime, see https://github.com/wbhart/flint2/pull/543  so now it's only the FreeBSD part that needs to be done.
Few obvious other candidates for a port in FreeBSD are gf2x and ecm.
Change History (65)
comment:1 Changed 4 years ago by
 Description modified (diff)
comment:2 Changed 4 years ago by
 Description modified (diff)
comment:3 Changed 4 years ago by
 Description modified (diff)
comment:4 Changed 4 years ago by
 Description modified (diff)
comment:5 Changed 4 years ago by
 Description modified (diff)
comment:6 Changed 4 years ago by
comment:7 Changed 4 years ago by
 Description modified (diff)
comment:8 Changed 4 years ago by
 Description modified (diff)
comment:9 Changed 4 years ago by
 Description modified (diff)
comment:10 Changed 4 years ago by
 Description modified (diff)
 Milestone changed from sage8.4 to sage8.5
comment:11 Changed 3 years ago by
comment:12 followup: ↓ 13 Changed 3 years ago by
I'm currently overextended as always and don't have any deep personal motivation to work on FreeBSD support, but I would definitely like to have it if we can so if there's anything I can help with here I'll make a FreeBSD 12 VM so I can have it to play around on.
comment:13 in reply to: ↑ 12 Changed 3 years ago by
Replying to embray:
I'm currently overextended as always and don't have any deep personal motivation to work on FreeBSD support, but I would definitely like to have it if we can so if there's anything. I can help with here I'll make a FreeBSD 12 VM so I can have it to play around on.
I can give you access to the FreeBSD 12.0 VM I am running on GCE, this would be easier, I guess. (12.0 is still in beta/RC cycle, so installation is not straightforward, you basically need to build it from source).
comment:14 Changed 3 years ago by
currently testing what we have here (with Sage 8.6) on the released FreeBSD 12.0
comment:15 followup: ↓ 16 Changed 3 years ago by
the next issue we hit is Python3 on Sage 8.7.beta3: https://bugs.python.org/issue6299 (pyexpat module does not build)
comment:16 in reply to: ↑ 15 Changed 3 years ago by
 Dependencies set to #27254
Replying to dimpase:
the next issue we hit is Python3 on Sage 8.7.beta3: https://bugs.python.org/issue6299 (pyexpat module does not build)
for the time being, working around this by not installing setuptools and pip for py3
comment:17 Changed 3 years ago by
 Dependencies changed from #27254 to #27254, #/26253
comment:18 Changed 3 years ago by
 Dependencies changed from #27254, #/26253 to #27254, #26253, #27262
 Description modified (diff)
comment:19 Changed 3 years ago by
 Description modified (diff)
comment:20 Changed 3 years ago by
 Dependencies changed from #27254, #26253, #27262 to #27254, #26253, #27262, #27764
 Description modified (diff)
 Milestone changed from sage8.5 to sage8.8
comment:21 Changed 3 years ago by
 Milestone sage8.8 deleted
As the Sage8.8 release milestone is pending, we should delete the sage8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage8.9).
comment:22 Changed 3 years ago by
 Description modified (diff)
 Milestone set to sagepending
to use flang (which is a possibility on FreeBSD at least), one needs

build/pkgs/numpy/spkginstall
a b export FFLAGS="$FFLAGS fPIC" 18 18 export FCFLAGS="$FCFLAGS fPIC" 19 19 20 20 export NUMPY_FCONFIG="config_fc noopt noarch" 21 21 export LDFLAGS="$LDFLAGS lexecinfo" # needed for flang 22 22 ################################################ 23 23 24 24 sagepython23 setup.py \
due to it being somewhat underlinked.
comment:23 Changed 3 years ago by
As I have to abandon the FreeBSD VM I've been using, I've pushed the current WIP branch to https://github.com/lwhsu/sagemath/commits/wip31082019
TBC on another FreeBSD machine.
comment:24 Changed 2 years ago by
A workinprogress has been submitted to the FreeBSD Phabricator:
https://reviews.freebsd.org/D24195
Its aim is to upgrade the existing port to 9.0.
Do not hesitate to comment or modify!
comment:25 Changed 2 years ago by
I think it'd be much better to use the work done on #27330  you don't even need to build a special Python version, but use one on the system! (And, of course, use autoconf, don't mess around with generated ./configure)
comment:26 Changed 2 years ago by
I used the external packages when this is possible with the released Sage 9.0. This version still builds the bundled Python. I guess that the progress done with #27330 will be available in the next release?
Thanks for your comment, I'll try to use autoconf.
comment:27 Changed 2 years ago by
A large part of #27330 is already in 9.0. But yes, I think it's much better to wait for 9.1, or actually start using 9.1.betas (we're near the first release candidate).
IIRC FreeBSD has quite a few packages available, although they aren't always built with prereqs needed for Sage, e.g. Flint is not built with NTL support.
comment:28 Changed 2 years ago by
Great! I'll try to work on 9.1 ASAP.
You are right about Flint: the ports used Cmake, and the NTL option is not available in CMakeLists.txt (and it is not even enabled by default with configure).
But we can change that, and I just sent a PR to fix it:
comment:29 Changed 2 years ago by
And I just added a port for Cliquer, from your autotoolized version:
comment:30 Changed 2 years ago by
Thanks. I suggest that every Sage library/package mentioned in #27330 be made a FreeBSD port (some of them are), this should be enough to finish this task.
We have plans to turn Sage into a "normal" pipinstallable Python library, but this probably won't happen before the end of the year.
comment:31 Changed 2 years ago by
I recently also added eclib, m4ri, gf2x, gp2c and the Pari packages (elldata, galdata, galpol, nftables and seadata).
And still going on!
comment:32 Changed 2 years ago by
Some news: I have just updated the WIPport to 9.1.beta9: it is available at https://reviews.freebsd.org/D24195
Every possible packages listed in #27330 are used as external packages, thanks for that!
Unfortunately, there remain some problems, mostly caused by staging (DESTDIR): a lot of libraries are referring to the directory where they have been built: e.g.
Error: 'lib/python3.7/sitepackages/PIL/_imagingft.so' is referring to /usr/ports/math/sage/work/stage Error: 'lib/libldl.so.2.2.6' is referring to /usr/ports/math/sage/work/stage
Is there some possibility to let them refer to relative directories? How would you set SAGE_LOCAL?
comment:33 Changed 2 years ago by
To be more precise: I have played with SAGE_LOCAL and SAGE_DESTDIR.
The logical choice seemed to set SAGE_LOCAL=$PREFIX and SAGE_DESTDIR=$STAGEDIR, but this is not the case.
comment:34 Changed 2 years ago by
Actually, to be more positive, it mostly works!
Looking for the root of the problem, only 29 libraries are not fully staged  but of course, thereafter the other binaries using one of this library become affected.
ATM (with 9.1.beta9), my list of affected libraries is:
libamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libamd.so.2
libbraiding.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libbraiding.so.0
libbrial_groebner.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libbrial_groebner.so.3
libbrial.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libbrial.so.3
libbtf.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libbtf.so.1
libcamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libcamd.so.2
libccolamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libccolamd.so.2
libcddgmp.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libcddgmp.so.0
libcholmod.so.3 => /usr/ports/math/sage/work/stage/usr/local/lib/libcholmod.so.3
libcolamd.so.2 => /usr/ports/math/sage/work/stage/usr/local/lib/libcolamd.so.2
libecl.so.16.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libecl.so.16.1
libfactory4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libfactory4.1.1.so
libfflas.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libfflas.so.1
libffpack.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libffpack.so.1
libgap.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libgap.so.0
libgc.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libgc.so.1
libhomfly.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/libhomfly.so.0
libiml.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/libiml.so.1
liblinbox.so.0 => /usr/ports/math/sage/work/stage/usr/local/lib/liblinbox.so.0
liblrcalc.so.1 => /usr/ports/math/sage/work/stage/usr/local/lib/liblrcalc.so.1
libomalloc0.9.6.so => /usr/ports/math/sage/work/stage/usr/local/lib/libomalloc0.9.6.so
libpolys4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libpolys4.1.1.so
libppl.so.14 => /usr/ports/math/sage/work/stage/usr/local/lib/libppl.so.14
libpynac.so.18 => /usr/ports/math/sage/work/stage/usr/local/lib/libpynac.so.18
libsingular_resources4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libsingular_resources4.1.1.so
libSingular4.1.1.so => /usr/ports/math/sage/work/stage/usr/local/lib/libSingular4.1.1.so
libsuitesparseconfig.so.5 => /usr/ports/math/sage/work/stage/usr/local/lib/libsuitesparseconfig.so.5
libumfpack.so.5 => /usr/ports/math/sage/work/stage/usr/local/lib/libumfpack.so.5
libzn_poly0.9.so => /usr/ports/math/sage/work/stage/usr/local/lib/libzn_poly0.9.so
Some of them like libgc, brial, or fflasffpack should be fixed RSN (thanks to #27330 ).
I guess that the most problematic case is libsuitesparseconfig.so, which is widely used.
comment:35 Changed 2 years ago by
 Cc mkoeppe added
I cc Matthias, who has been doing a lot of work on improving Sage's installation. He'd be able to understand the issue better than me, hopefully.
comment:36 Changed 2 years ago by
The problem is documented in build/pkgs/suitesparse/patches/03buildflags.patch:
"Note that L$(INSTALL_LIB) cannot be removed from LDFLAGS unless the package is broken into components. It is necessary as the components are progressively installed in INSTALL_LIB one after the other."
It has been reported in #28832 and fixed for OS X with install_name, but this does not fix it for FreeBSD. I'll have to try other patches  unless suiteparse could be used from a system package? It is not yet listed in #27330 but would be awesome!
comment:37 Changed 2 years ago by
Now we have #29502 for suitesparse  not done yet.
comment:38 Changed 2 years ago by
Some news: after #29502 for suitesparse and #29024 for singular, only 13 libraries (+ of course the modules built around them!) cause problems with staging: libbraiding libbrial_groebner libbrial libecl libfflas libffpack libgap libgc libhomfly liblinbox libppl libpynac libzn_poly0.
Among them, all are listed in #27330 (with or without a ticket), but libpynac. We do not even have pynac in the FreeBSD ports tree (but we have math/GiNaC) => it will be my next target.
comment:39 followup: ↓ 40 Changed 2 years ago by
After giac (#29541) and pynac (#29542), I tried to use a system package for ECL (lang/ecl) and Maxima (math/maxima), but without success for the moment: see #29617. To be tried again when ECL will be upgraded (#22191)!
Meanwhile, our ports must be patched:
 lang/ecl: add a symbolic link for $PREFIX/lib/ecl
 math/maxima: this one is more tricky, because now ECL is not even supported and must be added, and to get a useful package we need to replace the default from SBCL to ECL (or create a slave port?)
They are not submitted yet, but if someone want to work on #29617 the patches are available at
comment:40 in reply to: ↑ 39 Changed 2 years ago by
Replying to ghthierryFreeBSD:
After giac (#29541) and pynac (#29542), I tried to use a system package for ECL (lang/ecl) and Maxima (math/maxima), but without success for the moment: see #29617. To be tried again when ECL will be upgraded (#22191)!
Meanwhile, our ports must be patched:
 lang/ecl: add a symbolic link for $PREFIX/lib/ecl
 math/maxima: this one is more tricky, because now ECL is not even supported and must be added, and to get a useful package we need to replace the default from SBCL to ECL (or create a slave port?)
there are many free Common Lisp implementations, I suppose there can be lang/cl as a "main" package with a number of slaves, perhaps SBCL as a standard one.
comment:41 Changed 2 years ago by
I'd recommend to add system package information for FreeBSD. See https://trac.sagemath.org/ticket/29354 where this is done for Slackware (except for the bits that use docker)
comment:42 followup: ↓ 43 Changed 2 years ago by
Well, every package listed in #27330 have a corresponding package from the FreeBSD ports tree and a spkgconfigure.m4 to use it!
Next step: try to solve the problem with bad staging (nonrespect of $DESTDIR) for the libraries built by Sage.
comment:43 in reply to: ↑ 42 Changed 2 years ago by
Replying to ghthierryFreeBSD:
Well, every package listed in #27330 have a corresponding package from the FreeBSD ports tree and a spkgconfigure.m4 to use it!
Yes, and the trick is to put the names of these packages in a freebsd.txt file to record the correspondence of spkg to FreeBSD port.
comment:44 followup: ↓ 45 Changed 2 years ago by
OK, I'll do it!
comment:45 in reply to: ↑ 44 Changed 2 years ago by
comment:46 followup: ↓ 47 Changed 2 years ago by
Next, if you're serious about FreeBSD support, I would recommend setting up testing infrastructure with our tox.ini and virtualbox (https://www.freebsd.org/doc/handbook/virtualizationguestvirtualbox.html) or a similar solution so that Sage developers and our CI infrastructure have a chance of testing on that platform.
comment:47 in reply to: ↑ 46 Changed 2 years ago by
Replying to mkoeppe:
I would recommend setting up testing infrastructure with our tox.ini and virtualbox (https://www.freebsd.org/doc/handbook/virtualizationguestvirtualbox.html) or a similar solution so that Sage developers and our CI infrastructure have a chance of testing on that platform.
Thanks, this is interesting  but at this point a bit premature: there is no compilation error, but Sage is not yet ready for FreeBSD, even if we are making progress.
comment:48 Changed 2 years ago by
Well, we are almost done!
It is not yet committable in the FreeBSD ports tree, because there are some prerequisites (isl to be upgraded, and two possible forks for ECL and Maxima if no better solution is found).
See https://reviews.freebsd.org/D24195 for details.
comment:49 Changed 2 years ago by
for ecl I suggest to use a not yet merged https://trac.sagemath.org/ticket/22191
which looks good on Linux and OpenBSD.
also a new release of Flint is coming.
comment:50 Changed 2 years ago by
Thanks! I'm just in discussion with the maintainers of these two ports (ECL and Maxima). Let's check this version.
comment:51 Changed 2 years ago by
ecl obviously must be upgraded to the latest release (maxima currently packaged with Sage works well with it, too).
which bugs of maxima one prefers, is another question. :)
our experience with updating maxima is that each new release has serious regressions.
comment:52 Changed 2 years ago by
here is Flint update ticket https://trac.sagemath.org/ticket/29719
it is awaiting upstream putting in finishing touches here: https://github.com/wbhart/flint2/issues/753
comment:53 Changed 2 years ago by
I guess that it is safer to get Sage 9.1 into our ports tree with the current dependencies.
We'll look to upgrade these afterwards!
comment:54 followups: ↓ 55 ↓ 61 Changed 2 years ago by
We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/
and we are working on the upgrade of ECL to 20.4.24: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247283
comment:55 in reply to: ↑ 54 Changed 2 years ago by
Replying to ghthierryFreeBSD:
We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/
This is great!
I guess we should make the Sagemath source FreeBSDfriendly, so that one can build Sage from source using the standard ./configure + make route, right? This would need
 adding data for the needed packages, that is, there should be
build/pkgs/*/distros/freebsd.txt
files added with package names.
 adding prereqs data:
build/pkgs/freebsd.txt
andbuild/pkgs/freebsdbootstrap.txt
 import patches you added in FreeBSD to Sage (if any)
comment:56 Changed 2 years ago by
 Dependencies changed from #27254, #26253, #27262, #27764 to #26253, #27764
comment:57 Changed 2 years ago by
The most important patch concerns configure.ac: without it, you cannot even run configure!
I submitted it with the system package information in #29653, but it has been rejected.
The other patches are mostly specific and related to the ports system, caused by differences in directories, but shouldn't be necessary for those trying to build Sage by themselves with the bundled packages.
mkoeppe asked me to set up a testing infrastructure. I'm not familiar at all with that, but I'll try to do it (any pointers appreciated!).
comment:58 Changed 2 years ago by
I will look at #29653  it needs a rebase over the latest 9.2.beta1
regarding testing  is docker ported to FreeBSD?
Anyway, one can set a patchbot, for this one just needs a FreeBSD host that will pull branches and build/test them.
comment:59 Changed 2 years ago by
There exists a port of docker: https://www.freshports.org/sysutils/docker (but I never used it!).
comment:60 Changed 2 years ago by
I don't think docker port is production ready at the moment. I suggest the faster way would be having a github mirror and use hosted CI service: https://wiki.freebsd.org/HostedCI
comment:61 in reply to: ↑ 54 ; followup: ↓ 63 Changed 2 years ago by
Replying to ghthierryFreeBSD:
We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/
I've revived a VM with FreeBSD, it's running 12.1RELEASEp6
How do I get the new port in there? Do I need a system update (if yes, to what?)? Or it's easier? I've run portsnap, and still see old stuff for sage in /usr/ports/math/sage.
comment:62 followup: ↓ 64 Changed 2 years ago by
You did the right thing!
 12.1RELEASEp6 is OK
 `portsnap fetch update' is a well supported method  but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.
comment:63 in reply to: ↑ 61 Changed 2 years ago by
Replying to dimpase:
Replying to ghthierryFreeBSD:
We are done, 9.1 is in the tree: https://www.freshports.org/math/sage/
I've revived a VM with FreeBSD, it's running 12.1RELEASEp6
How do I get the new port in there? Do I need a system update (if yes, to what?)? Or it's easier? I've run portsnap, and still see old stuff for sage in /usr/ports/math/sage.
I guess there are two possibilities, one is portsnap is not updated yet (unlikely, IIRC it updates hourly), the other is it's tracking quarterly branch, and 9.1 is only in latest branch now. I haven't used portsnap for a while so I might also be wrong.
To get the latest ports tree in realtime, you can try to use svn to checkout from:
https://svn.freebsd.org/ports/head
or git from
comment:64 in reply to: ↑ 62 ; followup: ↓ 65 Changed 2 years ago by
Replying to ghthierryFreeBSD:
You did the right thing!
 12.1RELEASEp6 is OK
 `portsnap fetch update' is a well supported method  but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.
OK, thanks, seems to be in progress now, after I did portsnap fetch update
(my first try was portsnap fetch`  probably they are not the same thing)
lwhsu  did you see my email about CI? (just checking)
comment:65 in reply to: ↑ 64 Changed 2 years ago by
Replying to dimpase:
Replying to ghthierryFreeBSD:
You did the right thing!
 12.1RELEASEp6 is OK
 `portsnap fetch update' is a well supported method  but I do not know how long it takes to be refreshed. I guess that if you try again is 1h or 2 it should be fine.
OK, thanks, seems to be in progress now, after I did
portsnap fetch update
(my first try wasportsnap fetch`  probably they are not the same thing)
Yes there are two steps. One if for fetching the content and the other one is for actually updating the ports tree. See portsnap(8)
lwhsu  did you see my email about CI? (just checking)
Yes, please forgive me for needing longer to response.
This scipy problem is still there. (while this works with the system's python2) It's a matter of comparing the patches used there with what we do in Sage. Perhaps they disable multithreading...