I’m trying to use PackageCompiler.jl with a project that uses HTTP.jl (which depends on MbedTLS.jl), and it’s complaining that MbedTLS.jl is not relocatable (and the program also crashes, although I haven’t convinced myself yet that those are the same issue).
I think that using a _jll package solves this problem because of the way libraries are accessed (i.e., the path is not hard-coded into the program… but please correct me if I’m wrong). If so, is it possible to update MbedTLS.jl to use the MBedTLS library provided by MbedTLS_jll.jl?
The libraries are slightly different versions (2.13.1 vs 2.16.0), and I don’t know how much of an issue that is.
Any insight on this issue would be appreciated–thanks!
This doesn’t answer the question about relocatability but in case it’s helpful, I’ve been successfully using PackageCompiler.jl to build system images with HTTP.jl baked in over the last couple of months. Didn’t have any issues with MbedTLS. This was on Linux. We were creating a Docker image that could run a julia app without incurring jit overhead everytime we spin up a container.
GDAL alone worked on the first try (this is quite amazing tbh, given my PyInstaller experiences). For NetCDF I ripped BinDeps out in a local dev, and replaced it with a simple const libnetcdf = "libnetcdf". Then I went to the conda bin dir and copied the netcdf.dll and it’s dependencies to the compiled app’s bin dir, and it worked!
Yes, we build everything into the docker image and then just run the code inside containers launched from that image. To clarify a little more, I think my use of the word app was maybe a bit misleading. We build a julia system image into a docker image and then have a top level julia script as the image’s entrypoint. So when we launch the container it runs the top level script, which runs julia code that’s baked into the system image. The point of building everything into the system image is just to avoid compilation when the container starts up.