# Problems with executable compilation using PackageCompiler.jl

**URL:** <https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892>\
**Category:** General Usage\
**Tags:** compilation, binarybuilder\
**Created:** [July 1, 2019, 12:38pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892 "2019-07-01T12:38:19Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![vitreo12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vitreo12/32/4028_2.png) [@vitreo12](https://discourse.julialang.org/u/vitreo12)\
**Post date:** [July 1, 2019, 12:38pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/1 "2019-07-01T12:38:19Z")

</div>

Hello everyone,  
I was trying to build some julia code into command line applications with [PackageCompiler.jl](https://github.com/JuliaLang/PackageCompiler.jl), but I have noticed that, still, they do rely on compiling the functions, or parts of it, on first call.

As a working example, I have modified the [hello.jl](https://github.com/JuliaLang/PackageCompiler.jl/blob/master/examples/hello.jl) example file:

```julia
module Hello

using UnicodePlots

function plot_unicode_sine()
    println(lineplot(1:100, sin.(range(0, stop=2π, length=100))))
end

Base.@ccallable function julia_main(ARGS::Vector{String})::Cint

    @time a = 10 #Just to make sure that all things executed with @time are compiled...

    @time println("hello, world")
    @time println("hello, world")
    
    @time plot_unicode_sine()
    @time plot_unicode_sine()
    
    return 0
end

end

```

After compiling it to an executable using the `build_executable("hello.jl", "hello")` command, the resulting `./hello` executable gives me this output:

```julia
0.000000 seconds
hello, world
  0.006080 seconds (22 allocations: 1.547 KiB)
hello, world
  0.000043 seconds (4 allocations: 80 bytes)
      ┌────────────────────────────────────────┐ 
    1 │⠀⠀⠀⠀⠀⠀⠀⡠⠊⠉⠉⠉⠢⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⢠⠎⠀⠀⠀⠀⠀⠀⠘⢆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠳⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠳⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⢀⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢣⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⡎⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠼⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠬⢦⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⢤│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⠇│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡎⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡜⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⢆⠀⠀⠀⠀⠀⠀⢠⠎⠀⠀⠀⠀⠀│ 
   -1 │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠑⢄⣀⣀⣀⠔⠁⠀⠀⠀⠀⠀⠀│ 
      └────────────────────────────────────────┘ 
      0 100
  0.341968 seconds (936.42 k allocations: 45.406 MiB, 0.58% gc time)
      ┌────────────────────────────────────────┐ 
    1 │⠀⠀⠀⠀⠀⠀⠀⡠⠊⠉⠉⠉⠢⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⢠⠎⠀⠀⠀⠀⠀⠀⠘⢆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠳⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⠀⢠⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠳⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⢀⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢣⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠀⡎⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀│ 
      │⠼⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠬⢦⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⢤│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⠇│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡎⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡜⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠱⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡞⠀⠀⠀⠀│ 
      │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⢆⠀⠀⠀⠀⠀⠀⢠⠎⠀⠀⠀⠀⠀│ 
   -1 │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠑⢄⣀⣀⣀⠔⠁⠀⠀⠀⠀⠀⠀│ 
      └────────────────────────────────────────┘ 
      0 100
  0.002988 seconds (6.62 k allocations: 303.188 KiB)

```

which shows that both the `println("hello, world")` and `plot_unicode_sine()` functions have some compilation happening on their first call. Is this the expected result? Shouldn’t have `PackageCompiler` taken care of all the precompilation of all the called elements of the resulting executable/shared library?

---

<div class="post-metadata">

**Author:** ![gabrielfreire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabrielfreire/32/8799_2.png) [@gabrielfreire](https://discourse.julialang.org/u/gabrielfreire)\
**Post date:** [July 1, 2019, 1:26pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/2 "2019-07-01T13:26:00Z")

</div>

You need a Snoopfile that calls all your functions and cache the compiled code to package afterwards

```julia
# snoop.jl
using Hello
Hello.julia_main(String[])

```

And then

```julia
PackageCompiler.build_executable(...., snoopfile="path/to/snoop.jl")

```

But anyway, i could never get the same performance from an executable as if i was executing from a REPL session, REPL session cached compiled code is always much faster, `PackageCompiler` is useful but not production ready.

You can use the `SnoopCompile` package to generate additional snoop files.

I have two toy CLI tools in `Julia`  
[InstagramScraper](https://github.com/gabrielfreire/InstagramScraper.jl) and [FileCLI](https://github.com/gabrielfreire/FileCLI.jl) that i wrote just for fun and experimentation, check `./compile.jl`. Btw, i use my fork of [ApplicationBuilder](https://github.com/gabrielfreire/ApplicationBuilder.jl) to generate the Binaries.

Anyway, i had to write all my toy/not toy CLI tools in `C#` and some in `C++` because Julia still has big problems in terms of small binary generation.  
My final compiled build for `InstagramScraper` was `400mb` while my `C# .net core` `.exe` bundle was just `10mb`, both standalone.

Julia is not very versatile yet.

---

<div class="post-metadata">

**Author:** ![vitreo12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vitreo12/32/4028_2.png) [@vitreo12](https://discourse.julialang.org/u/vitreo12)\
**Post date:** [July 1, 2019, 1:37pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/3 "2019-07-01T13:37:14Z")

</div>

> [@gabrielfreire](#):
>
> You need a Snoopfile that calls all your functions and cache the compiled code to package afterwards
> 
> ```julia
> # snoop.jl
> using Hello
> Hello.julia_main(String[])
> 
> ```
> 
> And then
> 
> ```julia
> PackageCompiler.build_executable(...., snoopfile="path/to/snoop.jl")
> 
> ```

I tried it, and I got the same results as before: the first call to any of the functions still takes time in compiling whatever hasn’t been compiled yet. Could it be that the snooping does not actually catch every called function?

---

<div class="post-metadata">

**Author:** ![gabrielfreire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabrielfreire/32/8799_2.png) [@gabrielfreire](https://discourse.julialang.org/u/gabrielfreire)\
**Post date:** [July 1, 2019, 1:45pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/4 "2019-07-01T13:45:31Z")

</div>

I’m not sure what could be the issue with the precompile step with the snoopfile, but i’ve always noticed that the function `precompile(method, (Types...))` doesn’t do what i thought it did, also, the cache gathered from the Snoop file is never the same as the one used by a REPL session, it is just slower.

I feel it is a very terrible idea to make `CLI` tools in `Julia` at the moment.

---

<div class="post-metadata">

**Author:** ![vitreo12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vitreo12/32/4028_2.png) [@vitreo12](https://discourse.julialang.org/u/vitreo12)\
**Post date:** [July 2, 2019, 11:24am UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/5 "2019-07-02T11:24:52Z")

</div>

> [@gabrielfreire](#):
>
> I feel it is a very terrible idea to make `CLI` tools in `Julia` at the moment.

Yes, I am starting to realize that aswell. It’s kind of sad to not have a proper static compilation pipeline in Julia that would allow it to be used as a more generic programming language, giving its amazing features and syntax!

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [July 2, 2019, 11:32am UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/6 "2019-07-02T11:32:40Z")

</div>

> [@gabrielfreire](#):
>
> I feel it is a very terrible idea to make `CLI` tools in `Julia` at the moment.

> [@vitreo12](#):
>
> Yes, I am starting to realize that aswell. It’s kind of sad to not have a proper static compilation pipeline in Julia that would allow it to be used as a more generic programming language, giving its amazing features and syntax!

Getting a bit of topic, but have you experimented with `--compile=min`? For one-time scripts like a CLI that can be much faster, see e.g. the time comparisons here: [`jlpkg` -- a command line interface to Pkg](https://discourse.julialang.org/t/jlpkg-a-command-line-interface-to-pkg/24077)

---

<div class="post-metadata">

**Author:** ![vitreo12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vitreo12/32/4028_2.png) [@vitreo12](https://discourse.julialang.org/u/vitreo12)\
**Post date:** [July 2, 2019, 11:50am UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/7 "2019-07-02T11:50:08Z")

</div>

> [@fredrikekre](#):
>
> Getting a bit of topic, but have you experimented with `--compile=min` ? For one-time scripts like a CLI that can be much faster

Yes, I did try it for CLI stuff, but I am aiming to build fullly compiled applications, and I was trying `PackageCompiler` to build some simple tools to see if it could be useful to compile more complex things using Julia as the only programming language.

---

<div class="post-metadata">

**Author:** ![gabrielfreire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabrielfreire/32/8799_2.png) [@gabrielfreire](https://discourse.julialang.org/u/gabrielfreire)\
**Post date:** [July 2, 2019, 12:01pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/8 "2019-07-02T12:01:40Z")

</div>

It was a nice trick you used there, thanks for showing that, i didn’t know about that flag, it is great for CLI that interact directly with the Julia runtime and depends on Julia being installed on the system.

But doesn’t solve the issue for a standalone executable that can be distributed and installed anywhere.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [July 2, 2019, 12:47pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/9 "2019-07-02T12:47:57Z")

</div>

With regards to the extra compilation being done, maybe pass `--compile=no` to Julia running your custom sysimage. You should get an error when Julia tries to JIT a function that wasn’t precompiled. This should give us a hint as to what functions got missed.

---

<div class="post-metadata">

**Author:** ![vitreo12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vitreo12/32/4028_2.png) [@vitreo12](https://discourse.julialang.org/u/vitreo12)\
**Post date:** [July 2, 2019, 1:33pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/10 "2019-07-02T13:33:03Z")

</div>

> [@jpsamaroo](#):
>
> You should get an error when Julia tries to JIT a function that wasn’t precompiled. This should give us a hint as to what functions got missed.

The problem is that even with apparently simple functions, a lot of `"code missing for..."` errors would be printed out. Caching all of them into `precompile` statements and recompiling the system image looks like a workaround to a missing “official” way of building fully compiled executables, which I think is a big drawback for the adoption of the language (at least, among the people I know).

In any case, does anyone know if the feature of building fully compiled binaries is been worked on?

---

<div class="post-metadata">

**Author:** ![gabrielfreire](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabrielfreire/32/8799_2.png) [@gabrielfreire](https://discourse.julialang.org/u/gabrielfreire)\
**Post date:** [July 2, 2019, 1:47pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/11 "2019-07-02T13:47:37Z")

</div>

`PackageCompiler.jl` is apparently the official package for this task, if something is going to happen, like tree-shaking algorithms and those kind of stuff, it is going to happen there, but unfortunately, i’m not sure this is their focus at the moment, the developers are well aware of this query thou.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [July 2, 2019, 3:35pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/12 "2019-07-02T15:35:43Z")

</div>

> [@vitreo12](#):
>
> The problem is that even with apparently simple functions, a lot of `"code missing for..."` errors would be printed out.

These are exactly what I’m saying we need to fix: if these functions were AOT compiled into your sysimage properly, you wouldn’t get those errors anymore (my naive assumption).

> [@vitreo12](#):
>
> a workaround to a missing “official” way of building fully compiled executables, which I think is a big drawback for the adoption of the language (at least, among the people I know).

> [@vitreo12](#):
>
> In any case, does anyone know if the feature of building fully compiled binaries is been worked on?

Yes absolutely, but the problem is that there are less people working on fixing this than there are people who are asking for this functionality. Thankfully, there are a lot of low-hanging fruit (in my opinion) that are easy for new contributors to cut their teeth on. Given that I’m seeing plenty of enthusiasm in this thread, I’ll list some open issues that we all can work on:

- Remove unneeded stdlibs from `base/sysimg.jl` - The set of stdlibs included in the sysimage are listed here, and used during the build process to compile in support for stdlibs, which certain programs might not need (and removing them can save a big chunk of disk and memory usage). A PR to Julia to provide the option to remove these stdlibs at the user’s discretion would probably be a good start; alternatively, one could hack this support directly into PackageCompiler by swapping in a custom-written `base/sysimg.jl` to achieve the same effect.
- Certain core functionality may not be required - Add options to Julia’s build process that allow one to safely remove things like BLAS, and help fix the `src/anticodegen.c` file so that building with `JULIACODEGEN=0` in `Make.user` doesn’t break the build (which would remove runtime compiler support via the very hefty LLVM).
- Prototype some simple AOT codegen with LLVM in the CUDAnative style - CUDAnative has shown us that it’s possibly to AOT compile static kernels from within Julia for usage on the GPU. Doing native (CPU) codegen via the same approach, maybe with some tweaks for the specific program, would be an interesting avenue to explore, especially for smaller, simpler programs where dynamic dispatch might not be prevalent. This is pretty close to what “tree shaking” means, as you’re only compiling static code paths that are explicitly requested (and you can selectively remove things like exception machinery if you so desire).
- Fix SnoopCompile/Julia to catch more method signatures - As stated above
- Make things in the sysimage more compact - There’s certainly going to be holes or waste in the sysimage that are consistently unused, maybe due to overzealous padding or code/data duplication. Doing some spelunking into how Julia serializes and deserializes the sysimage should provide some insight into where things can be squished closer together to take up less room overall.
- Lazy-load parts of the sysimage - Currently, it appears that the entirety of the sysimage is loaded into memory at `julia_init`, which is probably not strictly necessary. Investigating ways to lazy-load chunks of the sysimage as-needed would reduce memory usage and potentially startup time.

---

<div class="post-metadata">

**Author:** ![asprionj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asprionj/32/6856_2.png) [@asprionj](https://discourse.julialang.org/u/asprionj)\
**Post date:** [August 14, 2019, 11:47am UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/13 "2019-08-14T11:47:56Z")

</div>

Just found this thread when running into similar problems. For me, using a snoop file which simply wraps the `julia_main` call worked. However, in both versions (with and without snoop file), there is an initial phase of about 6 seconds, during which nothing visible happens at all, then the `0.000000 seconds` shows from the `@time a = 10` statement.

Any idea where this “delay” comes from? There’s no such long delay when starting Julia… (BTW I tested this on Windows 8.1).

**Edit** : I just ran `compile_incremental` using the same snoop file (and a TOML with `UnicodePlots` as only dep), then executed `julia --sysimage <path/to/incremented/image> <snoopfile>.jl` and it has the usual almost negligible Julia startup time (some 0.2s or so) and then the same performance as the standalone executable. So it seems that the standalone executable does init-stuff which Julia does not…?

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [August 14, 2019, 12:39pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/14 "2019-08-14T12:39:09Z")

</div>

> [@asprionj](#):
>
> **Edit** : I just ran `compile_incremental` using the same snoop file (and a TOML with `UnicodePlots` as only dep), then executed `julia --sysimage <path/to/incremented/image> <snoopfile>.jl` and it has the usual almost negligible Julia startup time (some 0.2s or so) and then the same performance as the standalone executable. So it seems that the standalone executable does init-stuff which Julia does not…?

You should definitely file an issue, but unless you’re willing to investigate this yourself, I don’t think it will be addressed quickly. The maintainers are already extremely overloaded (and there are 95 open issues filed on the repo).

---

<div class="post-metadata">

**Author:** ![asprionj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asprionj/32/6856_2.png) [@asprionj](https://discourse.julialang.org/u/asprionj)\
**Post date:** [August 14, 2019, 3:19pm UTC](https://discourse.julialang.org/t/problems-with-executable-compilation-using-packagecompiler-jl/25892/15 "2019-08-14T15:19:23Z")

</div>

I’ll try the same at home, under Linux. Depending on the outcome, the starting point for investigating this behaviour would probably be different (OS-specific or not).

**Edit** : Tried it. `compile_incremental` works fine, but `build_executable` fails with

```julia
/home/linuxbrew/.linuxbrew/bin/ld: //home/asprionj/Documents/PortableSW/julia-1.1.0/lib/julia/libLLVM-6.0.so: undefined reference to `std::thread::_State::~_State()@GLIBCXX_3.4.22'
/home/linuxbrew/.linuxbrew/bin/ld: //home/asprionj/Documents/PortableSW/julia-1.1.0/lib/julia/libLLVM-6.0.so: undefined reference to `std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)())@GLIBCXX_3.4.22'
collect2: error: ld returned 1 exit status

```

So, cannot compare it right now.