Open dimpase opened 4 years ago
Great! We have a similar ticket for FreeBSD: see #26249. Some problems may be common between the two systems.
The common problem is a sorry state of Fortran support. OpenBSD has a very old g95 compiler (not updated since 2013), and flang - a llvm-based Fortran frontend, which is sort of developed by NVIDIA - except that NVIDIA is also working on a complete re-write, with flang on a back-burner.
On FreeBSD gfortran is not that bad:
$ gfortran9 --version
GNU Fortran (FreeBSD Ports Collection) 9.3.0
We had some problems (See https://wiki.freebsd.org/libgcc%20problem?highlight=%28fortran%29 ), but they have been solved.
see also #24712 - where an OpenBSD problem was mentioned with mpfr not finding symbols from compiler-rt library (which comes with clang).
Also, linbox calls NTL's to_ZZ
function with time(0)
, which is of type time_t
, and there is no prototype that understands this type.
Similar to a comment that I made on the FreeBSD porting ticket (#26249), also for OpenBSD I would recommend setting up testing infrastructure with our tox.ini and virtualbox (for freebsd see https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html) or a similar solution.
Making it easy to set up the development environment should be one of the first steps, not an afterthought when the porting is "complete". This will enable other Sage developers to help with that platform.
gfortran 8.3 on OpenBSD 6.7 can be installed by installing package g95 (sic!) which installs
egfortran
- which happens to be gfortran. It seems that they mixed up g95 (an old dormant project) and gfortran (which they tagged as obsolete)... Oh well.
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
Replying to @mkoeppe:
Similar to a comment that I made on the FreeBSD porting ticket (#26249), also for OpenBSD I would recommend setting up testing infrastructure with our tox.ini and virtualbox (for freebsd see https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html) or a similar solution.
Making it easy to set up the development environment should be one of the first steps, not an afterthought when the porting is "complete". This will enable other Sage developers to help with that platform.
one way to test on openbsd and freebsd would be to use https://man.sr.ht/builds.sr.ht/compatibility.md
of course it's yet another slightly different yaml: https://man.sr.ht/builds.sr.ht/#how-jobs-are-submitted
(although it does not look crazy, and it's well-supported)
the latest snag is Numpy: https://github.com/numpy/numpy/issues/19437 (while Singular more or less works...)
Singular is the current culprit.
Targetting OpenBSD 6.6+ with clang 8 and (perhaps) flang.
Many packages work out of the box, some packages are available from OpenBSD ports.
Install flang, git, gtar, gmake, gpatch, gmp, xz, yasm, zeromq, zlib, sqlite, pkg-config, python3.7, ncurses, boost, bzip2, curl, ecm, freetype, iconv, libffi, libgd, libpng, pcre. (this list is not checked atm).
For sanity (some of these compatibility issues probably can be fixed, but it's time-consuming for questionable gain), create and put to the PATH symlinks
tar -> gtar
,make -> gmake
,patch -> gpatch
. I am sticking with native shell (ksh), and it appears to work well (some bashisms are dealt with on ##29345) - Fortran (scipy) is the sticking point.Depends on #29345
CC: @thierry-FreeBSD
Component: porting: BSD
Issue created by migration from https://trac.sagemath.org/ticket/29677