PackageCompiler: issue with .exe file

#1

Hi all,

I create an .exe file with Build_Executable function from PackageCompiler. It works very well if I run it from my computer. If I want to share the executable file and run it on another computer it doesnt work. I get this error message

fatal: error thrown and no exception handler available.
#
rec_backtrace at /home/Administrator/buildbot/worker/package_win64/build/src\stackwalk.c:94
record_backtrace at /home/Administrator/buildbot/worker/package_win64/build/src\task.c:217 [inlined]
jl_throw at /home/Administrator/buildbot/worker/package_win64/build/src\task.c:417
jl_errorf at /home/Administrator/buildbot/worker/package_win64/build/src\rtutils.c:77
jl_load_dynamic_library at /home/Administrator/buildbot/worker/package_win64/build/src\dlload.c:197
jl_get_library at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\runtime_ccall.cpp:50
jl_load_and_lookup at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\runtime_ccall.cpp:61
jlplt_g_type_init_7094 at C:\Users\fv973uv\Desktop\Executable\IFRS17.dll (unknown line)
init__gtype at C:\Users\mehdi.barbouche.julia\packages\Gtk\RwVPb\src\GLib\signals.jl:329
init at C:\Users\mehdi.barbouche.julia\packages\Gtk\RwVPb\src\GLib\signals.jl:392
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src\gf.c:2219
jl_apply at /home/Administrator/buildbot/worker/package_win64/build/src\julia.h:1571 [inlined]
jl_module_run_initializer at /home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:72
_julia_init at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\init.c:832
.text at C:\Users\fv973uv\Desktop\Executable\IFRS17.exe (unknown line)
__tmainCRTStartup at /home/abuild/rpmbuild/BUILD/mingw-w64-crt\crt\crtexe.c:339
mainCRTStartup at /home/abuild/rpmbuild/BUILD/mingw-w64-crt\crt\crtexe.c:223
BaseThreadInitThunk at C:\Windows\System32\KERNEL32.DLL (unknown line)
RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)

any help?

#2

Hi,
To run a compiled julia executable on another machine, you’ll have to transfer the julia runtime libraries in addition to the exe itself. The new machine will have to be able to find a compatible libjulia.dll (in the lib directory of your julia installation) and all the dlls in the lib/julia directory if I’m not mistaken.

#3

Looks like you are trying to build a package that uses Gtk. I’ve managed to relocate a Gtk application on mac OS but it’s not straightforward. The issue is that you need to move all the Gtk’s dll and external file in addition to the Julia ones. And the relative/absolute paths need to be correct. On mac OS you can modify libraries that depends on others to modify their paths, I’m not sure how it works on windows.

Other Julia packages might have similar issues, there’s sometimes hard-coded absolute paths that need to be taken care of.

There’s an example in ApplicationBuilder with SDL:

And I have this build script for mac OS, I’m not 100% sure it’s up to date though:

#4

Same issue here. Did you manage to make it work?

#5

Which packages do you use ? Gtk as well ?

#6

Hi, thank you for your answer! No, I am actually looking for a generic way of generating a standalone .exe file from julia code that I could send to someone else who does not have julia installed. A simple code that would read some text input, do some calculations and generate some text or ideally also some plots output. I generally use DifferentialEquations, LinearAlgebra, SparseArrays.
I was able to compile that to an executable that runs on my computer with PackageCompiler, but not on others :frowning:

#7

What kind of error do you get, is it a missing library like above ? What I did for testing if my executable was portable was to temporarily rename my .julia folder, so if the executable was looking for files in there it would crash (testing each time on another computer is cumbersome).

#8

Yes, it is missing libraries. The error reads:
fatal: error thrown and no exception handler available.

#

rec_backtrace at /home/Administrator/buildbot/worker/package_win64/build/src\stackwalk.c:94

record_backtrace at /home/Administrator/buildbot/worker/package_win64/build/src\task.c:217 [inlined]

jl_throw at /home/Administrator/buildbot/worker/package_win64/build/src\task.c:417

error at .\error.jl:33

check_deps at C:\Users\jibezaba.julia\packages\SpecialFunctions\fvheQ\deps\deps.jl:16

init at C:\Users\jibezaba.julia\packages\SpecialFunctions\fvheQ\src\SpecialFunctions.jl:12

jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src\gf.c:2219

jl_apply at /home/Administrator/buildbot/worker/package_win64/build/src\julia.h:1571 [inlined]

jl_module_run_initializer at /home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:72

_julia_init at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\init.c:832

.text at C:\Users\jibezaba\Desktop\builddir_diffeq\diffeq.exe (unknown line)

__tmainCRTStartup at /home/abuild/rpmbuild/BUILD/mingw-w64-crt\crt\crtexe.c:339

mainCRTStartup at /home/abuild/rpmbuild/BUILD/mingw-w64-crt\crt\crtexe.c:223

BaseThreadInitThunk at C:\Windows\System32\KERNEL32.DLL (unknown line)

RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)

#9

The problem is that the package SpecialFunctions downloaded and installed a library on your machine in the build step when you added the package. You can see in the deps/deps.jl file in that package (in your package directory) that it wants to load the library:

const openspecfun = joinpath(dirname(@__FILE__), "usr\\bin\\libopenspecfun.dll")

Which doesn’t work on another machine because it doesn’t have this file (libopenspecfun.dll), and SpecialFunctions crashes when it tries to load it.

The solution is to copy and ship this file (and all others that are needed) alongside your executable.

That said I’m not sure where the file is supposed to be placed, i.e. what does joinpath(dirname(@__FILE__), "usr\\bin\\libopenspecfun.dll") means in the context of the compiled executable ?

#10

Thank you for the tip on changing .julia folder to test on the same computer :slight_smile: I will try to gather the missing dll files. It would be nice to be able to compile it down to a standalone .exe as with Fortran or C code.

#11

Note there’s an option in ApplicationBuilder to copy libraries but I don’t know how well it works (it’s been developed for macOS I think). There’s a bit of work to be done to streamline this process, but not many people have tried ship executable it seems.

#12

You can change the location of the library before the build. For example here I replace the hardcoded path to the library (something like /home/.../.julia/packages/.../libopenspecfun.so) to libopenspecfun.so (which then needs to be placed alongside the binary):

using SpecialFunctions
Base.eval(SpecialFunctions, :(openspecfun = basename(openspecfun)))

See also https://github.com/JuliaLang/PackageCompiler.jl/issues/86

2 Likes
#13

Thanks! I finally managed to make it work. For someone else having the same issue, I had to modify the deps.jl file in .julia/packages/SpecialFunctions and change:

const openspecfun = joinpath(dirname(@__FILE__), "usr\\bin\\libopenspecfun.dll")

to:

const openspecfun = "libopenspecfun.dll"

Then I could compile and just copy libopenspecfun.dll to the folder where the .exe runs. Then deps.jl needs to be changed back to its original form in order to use the other packages normally.
I guess that’s exactly what you did in a more elegant manner with that command, but I could not get it to work.