# USE\_SYSTEM\_ and artifacts on FreeBSD

**URL:** <https://discourse.julialang.org/t/use-system-and-artifacts-on-freebsd/142910>\
**Category:** General Usage\
**Tags:** devdiscussion\
**Created:** [November 12, 2026, 2:44pm UTC](https://discourse.julialang.org/t/use-system-and-artifacts-on-freebsd/142910 "2026-11-12T14:44:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![thierry-FreeBSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thierry-freebsd/32/225200_2.png) [@thierry-FreeBSD](https://discourse.julialang.org/u/thierry-FreeBSD)\
**Post date:** [November 12, 2026, 2:44pm UTC](https://discourse.julialang.org/t/use-system-and-artifacts-on-freebsd/142910/1 "2026-11-12T14:44:33Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 12, 2026, 3:15pm UTC](https://discourse.julialang.org/t/use-system-and-artifacts-on-freebsd/142910/2 "2026-11-12T15:15:08Z")

</div>

Welcome!

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:

> <https://github.com/JuliaLang/julia/pull/33125/files>
>
> Provide libexpat, libz and p7zip (true 7z for Windows) on all platforms. This p…rovides a number of benefits:
> 
> \* Significantly reduces the amount of work in \`win-extras\`, which I've always thought was an annoying wart in our build system.
> 
> \* Provides a consistent \`7z\` executable on all platforms, which can be picked up by \`Pkg\`/\`BinaryProvider\` for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, \`7z\` is a repackaged binary from sourceforge and is the "full" \`7z\`, whereas on all other platforms it is a \`p7zip\` build of the standalone \`7za\` executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine.
> 
> \* We kind of half-heartedly guaranteed to packages like WinRPM (through \`LibExpat.jl\`) that \`libexpat\` would always be available. This is inconsistently true across platforms, so let's fix that by just shipping it everywhere just like any other dependency.

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.

Use latest version, I see at least one patch;

> **[Blaming julia/deps/patches/libssh2-CVE-2026-66033.patch at v1.13.3 ·...](https://github.com/JuliaLang/julia/blame/v1.13.3/deps/patches/libssh2-CVE-2026-66033.patch)**
>
> The Julia Programming Language. Contribute to JuliaLang/julia development by creating an account on GitHub.