Hello,
I have just upgraded the FreeBSD port of Julia, and I have some remarks.
I wanted to define USE_SYSTEM_ZLIB=1 and USE_SYSTEM_OPENSSL=1, in order to use the system libraries (specially for OpenSSL, for which reactivity is necessary in case of security issues), but this is not possible:
the artifacts used to build the docs (and many others) are linked to libz.so.1, while we have now libz.so.6;
same problem with SSL libssl.so.3 vs. libssl.so.35;
some artifacts are even linked with libgssapi.so.10 (heimdal, replaced by MIT Kerberos in recent FreeBSD).
I solved the problem of libgssapi by using the port compat14x.
I could solve the other library problems with /etc/libmap for my personal usage, but I cannot package it. I could try to solve it with symbolic links, but it’s a source of potential problems…
I’ve seen the possibility of share/julia/artifacts/Overrides.toml but it seems fragile, and might break when we update some libraries.
I have read the thread “BSD on ARM”, saying that there is an infrastructure problem.
Would it be possible to provide a script, in order to build the artifacts ourselves? (at least the most used)
As you likely know FreeBSD is only tier 2, and on Arm only tier 3:
Tier 2: Julia is guaranteed to build from source using the default build options ..
Tier 3: Julia may or may not build. If it does, it is unlikely to pass tests
I started looking into the Makefile for USE_SYSTEM_ZLIB and I see zlib was added a long time ago then version 1.2.11 here:
Changing some of the options like USE_SYSTEM_BLAS, is I believe not really supported, done for testing, I don’t know about the others. You can of course do whatever in private, most need not recompile… I doubt non-default build options will ever be supported, officially, and I think it’s up to users to test, and come up with scripts, at least for less supported platforms like FreeBSD. But I’m not on official person here, so I’m guessing. For security we rely on juliaup to update Julia itself and then OpenSSL too.