Static compilation on 1.0 - DLL error due to static absolute paths

General Usage
1

Hi,
I’m trying to deploy a DLL compiled with latest PackageCompiler.jl on Julia1.0 to a different computer. I’ve found a severe problem with loading of DLLs of used packages. The trouble-making DLL’s are:

  • libopenspecfun.dll from SpecialFunctions,
  • libRmath-julia.dll from Rmath
  • libddierckx.dll from Dierckx

All of them use hardcoded (from static compillation point of view) dll location using a common construct, e.g.
const libddierckx = joinpath(dirname(@__FILE__), "usr\\bin\\libddierckx.dll")

Could you please point me to a workaround or explanation how one could mitigate these hard-coded paths so that the libs (DLLs) load from one directory (the same where libjulia.dll etc. live)?

The problem is, also whenever I run pkg"gc" then there is high chance a newer version of the package exists and the old is deleted, making the static compiled work unusable. I’m happy to send an PR but I don’t know where to start or if this is a known bug, backlog issue or strategic core-dev decision.

2

I’ve looked into issues on the BinaryProvider/BinaryBuilder.jl duo that is responsible for creating the deps.jl file. Seems to me that there is some ongoing activity but mainly driven by the need not to copy binary dependencies (only updated once a while) with every single, even minor release of the given package. I’ve looked into the Bb roadmap and I’m missing anything related to static compilation+deployment.

Should I fill an issue into BinaryProvider to discuss the implementation?

3

xref BinaryBuilder #392

4

I’m not familiar with the particular problem, but yes, it sounds like filling an issue with BinaryProvider would be totally appropriate.

5

The problem is quite complicated and the package ecosystem hasn’t been been designed with this in mind. My understanding is that in the worse case you have to do the following:

  1. Copy the packages and libraries such that they are in a proper relative path.
  2. Modify libraries/resources paths in the packages (either by editing the file or by evaling).
  3. Modify the libraries (which sometimes also contains absolute paths).

You can also check the examples in ApplicationBuilder.jl.

6

Something I’m confused about is the following:

On MacOS application have a folder structure like this:

Contents:
    /MacOS/
    /Libraries/

With the main binary in MacOS and other libraries in Libraries/...

So relatives paths in my executable should point to ../Libraries/Lib1/lib1.dylib, so I need to modify library paths in my package to reflect that ?

7

Right now as a quick one time solution I"ll only dev all the problematic packages and modify the deps.jl files to have a fallback to rative path (only filename). But finally I think this should be fixed on the BinaryBuilder.jl level to reach every package.

8

For now, a workaround to the problem is described here.

It is indeed hacking each deps.jl file…