Missing Relocatability of Tulip


I try to compile a project into an application that depends on Tulip.jl, but the resulting App is not portable, see:

Has someone managed a similar situation and has some advice.
Is it possible to handle this missing relocatibility inside my project or is it necessary that this issue need to be handled inside the conflicting package Tulip.jl?

You might want to consider calling real_main from __init__() rather than the module top level.

Thanks for the idea with __init__()!
I found the function __init__() in the project Tulip.jl does it make sense to fork the project and add something myself into this function?
And if so, can someone suggest a good example what and how to do this?

See Modules · The Julia Language

Looking at fatal: error thrown and no exception handler available. · Issue #789 · JuliaLang/PackageCompiler.jl · GitHub I see the __init__ of Tulip is an issue.

We probably do not need to load the version number loke that on module load. For your purposes,

using Pkg
pkg"dev Tulip"

This will clone Tulip into your .julia/dev folder.

Then modify Tulip’s __init__ as follows:

function __init__()
    _TULIP_VERSION[] = v"0.9.4"

There is a better way to do this with Pkg, but this will work for you for now.

For this particular case there is no need for an __init__ at all, the version number can be set during precompilation (Tulip.jl#132).

1 Like

The problem is not the content of function __init()__.
The package Tulip is not even listed in the Project.toml of the project that I try to compile into a portable application. One of the packages used relay on it. :frowning:
The main issue is the missing Relocatibility of Tulip.jl

Look at the error you reported on the PackageCompiler.jl issue:

InitError(mod=:Tulip, error=ErrorException(""C:\\Users\\stefanpofahl\\.julia\\packages\\Tulip\\BVHPO\\src\\..\\Project.toml":
 No such file"))

Why is it looking for that file?

It’s because of this line:

    tlp_ver = VersionNumber(TOML.parsefile(joinpath(@__DIR__, "..", "Project.toml"))["version"])

Get rid of that line, then that is one less issue to deal with.

1 Like

@fredrikekre & @mkitti
First of all thank you for your help! :slight_smile:
It was haphazardly that I included the function Tulip.__init__() in my minimal example
and it was not obvious to me that this was already the part of the Tulip-code that causes the trouble.

Ok, I understand the root cause of my problem. Consistently, I have added my local clone of Tulip.jl as development package to the primary environment, but this does not cure the problem :frowning:
During package compilation the standard Tulip.jl is taken to build the library “sys.dll”.
Is there a way to specify the local Tulip.jl-package to be utilized during package compilation?

You would want to create specific environment for your project, and then dev your local copy into that environment. I would not recommend using the default primary environment (e.g. @1.8 or @1.9) for this purpose. In fact, I would consider backing up that primary environment (copy the Project.toml and Manifest.toml) and clearing it out to make sure it does not interfere with system image building. Then, I would activate an environment in a local folder and add exactly the packages you need via Pkg.add or Pkg.dev.

To clarify, Tulip.__init__() will be invoked the first time your code does using Tulip.

Thanks, for the idea! - It seems that the PackageCompiler is a little bit an anarchist, …
Meanwhile I did exactly this. I established my own primary environment and added the local clone of Tulip in this private primary environment. And started in this environment the process create_app().
But PackageCompiler took again the wrong version of Tulip :frowning:

Could you should the result of the following in the activated environment?

using Pkg
pkg"status -m"

Paging @kristoffer.carlsson

Just to make sure, consider bumping the version number of your Tulip.jl clone and make sure that version is added to the environment. Another consideration, is to create a git branch, commit your changes, and add it via add /path/to/Tulip.jl#branchname.

julia> pkg"status"
      Status `C:\Users\stefanpofahl\.julia\environments\v1.6\MyAppCompileEnv\Project.toml`
  [9b87118b] PackageCompiler v2.1.5
  [295af30f] Revise v3.5.1
  [6dd1b50a] Tulip v0.9.4 `https://github.com/ds4dm/Tulip.jl.git#master`

the output of pkg"status -m" is quite long, it includes more then 20 packages.
I have coded a script compile_app.jl to control the compilation procedure, myabe it is of interest for some of you.

Meanwhile, the package maintainer of Tulip.jl agreed to publish a new version.
Therefore, the Tulip-issue might be resolved soon.
But the topic / question remains:
How can I specify, which version of a package (a local development version or a registered one) is going to be taken for the compilation.

As you can see from the status, the version of Tulip.jl that you are using in your environment is the master branch of the Github version, not your local copy.

You either need to dev the package pointing to the local copy or use add the package as I noted above.

using Pkg
pkg"dev /local/path/to/your/modified/Tulip.jl"

Thank you so much for your tips! - I still not know what my mistake was,
I really tried to make it correct.
As the master-branch is already fixed, I used:
pkg> add Tulip#master

This made the error disappear.

Unfortunately, I found the next issue:

The problematic part is the following line in side LLVMExtra_jll:

artifacts_toml = joinpath(dirname(@__DIR__), "Artifacts.toml")

Any suggestions, how to modify this part of the code?

In Julia v1.8.5 I am able to compile a portable app containing “Tulip.jl” :slight_smile:

I found some bugs in my compile_app.jl-script these errors are fixed now.
I am open for further corrections and suggestions.

New version of compile script is online: compile_app.jl