# Will juliac solve the relocatabiliy issue?

**URL:** <https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780>\
**Category:** General Usage\
**Tags:** question\
**Created:** [August 22, 2025, 7:35pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780 "2025-08-22T19:35:14Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 22, 2025, 7:35pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/1 "2025-08-22T19:35:14Z")

</div>

I have found that generating an app using PackageCompiler.jl only works for kind of academic examples since any dependency potentially breaks relocatabiliy. Our solution to this is to actually use docker images and bundle everything. Fine for deployed software but not really for “normal” users.

Will juliac solve this problem?

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 22, 2025, 7:47pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/2 "2025-08-22T19:47:32Z")

</div>

To the best of my knowledge this is an un-related problem that can be solved separately.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 22, 2025, 8:01pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/3 "2025-08-22T20:01:49Z")

</div>

> [@ufechner7](#):
>
> To the best of my knowledge this is an un-related problem that can be solved separately.

Unrelated to what? Isn’t the goal of juliac to build standalone executables?

> [@Julia slower than Python for finding pangrams?](https://discourse.julialang.org/t/julia-slower-than-python-for-finding-pangrams/112481/8):
>
> The good news is that we’re getting closer to having a real `juliac` that can output compiled stand-alone executables with significantly lower startup times like `cc` does.

The usefulness is very limited if they are not relocatable.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 22, 2025, 8:08pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/4 "2025-08-22T20:08:54Z")

</div>

> [@ohmsweetohm1](#):
>
> Unrelated to what?

Unrelated to reducing the code size of the compiled shared library or executable which is the main goal of juliac.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 22, 2025, 8:34pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/5 "2025-08-22T20:34:27Z")

</div>

At least when reading about it, it didn’t sound that way.

> **[juliac](https://jbytecode.github.io/juliac/)**

> The --trim option is mandatory for generating smaller binaries. If you don’t use it the compiler will generate a binary file that is not trimmed.

Also the JuliaCon 2024 talk sounds different.

[![](https://global.discourse-cdn.com/julialang/original/3X/8/2/8279c7b51ca9cc3d4ce14f9da95cf9331735c332.jpeg "New Ways to Compile Julia | Bezanson, Baraldi | JuliaCon 2024") ](https://www.youtube.com/watch?v=MKdobiCKSu0)

`--trim` is a part of the juliac app building, but not essential.

But maybe we are both right. v1.12 will add the first ability to produce small stand alone executables. But it will not work for every case as the relocatabiliy issue is not solved.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 22, 2025, 8:42pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/6 "2025-08-22T20:42:14Z")

</div>

> [@ufechner7](#):
>
> Unrelated to reducing the code size of the compiled shared library or executable which is the main goal of juliac.

Was compiling a fully linked shared library or executable possible before?

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 22, 2025, 8:50pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/7 "2025-08-22T20:50:46Z")

</div>

> [@ohmsweetohm1](#):
>
> Will juliac solve this problem?

it “solves” the problem across micro architecture (`JULIA_CPU_TARGET`), which PackageCompiler.jl can do already. But you won’t be able to cross-compile (e.g. from x86\_64 to aarch64) (because Julia itself doesn’t)

[https://indico.cern.ch/event/1515852/contributions/6599313/attachments/3104673/5502050/Jerry\_Ling\_StaticJulia.pdf#page=27](https://indico.cern.ch/event/1515852/contributions/6599313/attachments/3104673/5502050/Jerry_Ling_StaticJulia.pdf#page=27)

---

<div class="post-metadata">

**Author:** ![nhz2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhz2/32/44428_2.png) [@nhz2](https://discourse.julialang.org/u/nhz2)\
**Post date:** [August 22, 2025, 9:02pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/8 "2025-08-22T21:02:30Z")

</div>

> [@ohmsweetohm1](#):
>
> any dependency potentially breaks relocatabiliy

How would that happen, and is there a way for dependencies to test for this kind of breakage?

---

<div class="post-metadata">

**Author:** ![RomeoV](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/romeov/32/37687_2.png) [@RomeoV](https://discourse.julialang.org/u/RomeoV)\
**Post date:** [August 23, 2025, 1:44am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/9 "2025-08-23T01:44:38Z")

</div>

FWIW I am currently building a relocatable julia library, wrapped into a python module (but can be used as an executable or C library aswell). See [here](https://github.com/RomeoV/RunwayLib.jl?tab=readme-ov-file#python-usage) and also the discussion in [Creating fully self-contained and pre-compiled library](https://discourse.julialang.org/t/creating-fully-self-contained-and-pre-compiled-library/131374). However, it is true that this has similar amounts of relocatability as PackageCompiler.jl but comes with the extra guarantee that no further code will be compiled at runtime. My goal is currently just to support x86 Linux usecases with glibc\>=2.30. This is going well (after quite some effort). Do you need relocatability also to other architectures? In that case it may be possible to make separate builds for x86 and arm and different OSes and then handle somehow that the target system downloads the correct version (common usecase for package managers). In theory I believe this will be no problem.

For an example of the “relocatability” you can check [this github workflow file](https://github.com/RomeoV/RunwayLib.jl/blob/master/.github/workflows/juliac.yml) which first builds the library on one machine and then tries to run it on another machine.

---

<div class="post-metadata">

**Author:** ![RomeoV](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/romeov/32/37687_2.png) [@RomeoV](https://discourse.julialang.org/u/RomeoV)\
**Post date:** [August 23, 2025, 1:47am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/10 "2025-08-23T01:47:56Z")

</div>

> [@ohmsweetohm1](#):
>
> any dependency potentially breaks relocatabiliy

Actually, can you elaborate what you mean by this? Generally I don’t think this is true, dependencies should work fine with juliac and PackageCompiler alike.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 23, 2025, 3:21am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/11 "2025-08-23T03:21:05Z")

</div>

> [@RomeoV](#):
>
> My goal is currently just to support x86 Linux usecases with glibc\>=2.30

well, you need worry more about downloading Julia right? because everything links to Julia runtime (or am I dreaming)

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [August 23, 2025, 4:36am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/12 "2025-08-23T04:36:31Z")

</div>

> [@RomeoV](#):
>
> Actually, can you elaborate what you mean by this?

I think they’re referring to the fact that any dependency can potentially rely on paths created through `@ __FILE__ `, or simply assuming a specific working directory and blindly opening files relative to that. `juliac` won’t help with detecting that.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 23, 2025, 4:53am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/13 "2025-08-23T04:53:38Z")

</div>

> [@Sukera](#):
>
> rely on paths created through `@ __FILE__ `, or simply assuming a specific working directory and blindly opening files relative to that

If I’m understanding this right, this works for the typically locally installed packages because those relative paths are freshly evaluated for the local installation during precompilation, but it doesn’t work for a relocated AOT compiled product because the paths are stuck at the machine that compiled it? Something else to check, this should be fine for some things like precompile-time `include`s, right, it’s only a problem if those paths are used at runtime?

OP might be talking about something else, so if that’s the case I don’t want to derail anything.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 23, 2025, 6:14am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/14 "2025-08-23T06:14:23Z")

</div>

> [@RomeoV](#):
>
> Actually, can you elaborate what you mean by this?

I mean relocatabiliy as it is stated in the PackageCompiler.jl docs.  
I’ll give a few examples:

If I currently build an app with Oxygen.jl and run it on another machine, I cannot open the docs endpoint, since there is a js bundle missing where it points to the build machine.

I had the same problem with MakieGL.jl where some files were missing. And if I started the app it accessed the Pkg server and downloaded some artifact, totally unacceptable.

The problem is, that this is some kind of a code quality issue for each package. I think, however it has to be handled at language level.

It is not about cross compilation. Although that would be nice too. However I can achieve that using emulation, e.g. in docker, it is just really slow.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 23, 2025, 6:23am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/15 "2025-08-23T06:23:25Z")

</div>

New juliac JuliaCon talk

[![](https://global.discourse-cdn.com/julialang/original/3X/1/2/12fa5e10cf4cb7d9ce095a664bb75bccf424abe6.jpeg "JuliaCon Global 2025 | REPL Main Stage | Day 1") ](https://www.youtube.com/watch?v=3o0lAXCa9Wg)

Starts at 6:50:20

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [August 23, 2025, 9:31am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/16 "2025-08-23T09:31:20Z")

</div>

Please open an issue if you run into relocatability problems with GLMakie. We specifically test that basic relocation works in CI, but maybe the tests could be improved

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 23, 2025, 9:46am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/17 "2025-08-23T09:46:14Z")

</div>

> [@ohmsweetohm1](#):
>
> I mean relocatabiliy as it is stated in the [PackageCompiler.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/PackageCompiler) docs.

Link to Relocatability section for discovery: [Apps · PackageCompiler](https://julialang.github.io/PackageCompiler.jl/stable/apps.html#relocatability). Applies to apps and libraries, not sysimages.

> [@ohmsweetohm1](#):
>
> this is some kind of a code quality issue for each package. I think, however it has to be handled at language level.

That can only go so far. Nothing stops people from making a program that tries to open a file at a path that may not exist; end-users may even be instructed to manually make the path and files for the program to work (I really don’t like how often this has happened to me). Even most of the things we shouldn’t do at precompilation, which also automatically runs during installation like the build system discussed in the Relocatability section, can’t be prevented automatically; maybe I really did want to [run `rand` at precompile-time](https://www.oxinabox.net/2023/06/16/top-level-code-in-julia.html). I expect there to be case-by-case issues for implementing relocatability just as there were many issues for implementing 1.9+ precompilation. There should be improvements and documented practices for relocatability over time, though, this isn’t something people should keep stumbling into and guessing.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 23, 2025, 10:27am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/18 "2025-08-23T10:27:50Z")

</div>

> [@Benny](#):
>
> That can only go so far. Nothing stops people from making a program that tries to open a file at a path that may not exist

True, but if think this should be alerted to the user. It might be a mistake that at precompile time a path is stored in the package scope somewhere. I would propose for this to even be forbidden by the compiler. Are there any good reasons for it?

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 23, 2025, 11:45am UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/19 "2025-08-23T11:45:54Z")

</div>

If you mean a `String` being assigned to a global variable or a field/element of an object assigned to a global variable, then obviously nothing should stop that. A string that looks a lot like a file path may not be one. A path may not be dangerous if it’s only read at precompile-time (most `include`s) or it’s being written to. Besides, I think that’s breaking; every unrelocatable dependency suddenly becomes unusable.

---

<div class="post-metadata">

**Author:** ![ohmsweetohm1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ohmsweetohm1/32/49126_2.png) [@ohmsweetohm1](https://discourse.julialang.org/u/ohmsweetohm1)\
**Post date:** [August 23, 2025, 12:36pm UTC](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780/20 "2025-08-23T12:36:27Z")

</div>

Ok, it seems there is no easy fix, which is probably why it hasn’t been done. However, I feel that the goal of juliac should be to deliver “small _relocatable_ stand alone executables”. 😉

For now what could be done to at least check if a package is surely relocatable or not? Could I somehow regex for paths? Could this new tracing stuff for `--trim` be used to check if a path to the host machine is used ever again and warn? If I build some software and distribute it to a customer or simply another user, I would like it to work.

And just for my understanding, the juliac executable will eventually be the thing that make\_app from PackageCompiler.jl produces?

[Next page](https://discourse.julialang.org/t/will-juliac-solve-the-relocatabiliy-issue/131780.md?page=2)