You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 16, 2023. It is now read-only.
I’m trying to deploy a DLL compiled with latest PackageCompiler.jl 1 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 a static compilation point of view) dll location using a common construct, e.g. const libddierckx = joinpath(dirname(@FILE), "usr\bin\libddierckx.dll")
All of them have the deps.jl generated by BB/BP with assumption their location is an absolute path. We should mitigate these hard-coded paths so that the libs (DLLs) load from one directory (the same where libjulia.dll etc. live) for static compilation? Or, if the library not found in the expected location, let libdl locate the DLL and try to use it?
The problem is, also whenever I run pkg"gc" then there is a 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 a PR but I don’t know where to start or if this is a known bug, backlog issue or strategic core-dev decision. I' ve read the BB roadmap but no mention of static compilation/deployment has been discussed there.
Thank you for any workaround suggestion and any hint how this might get solved - I'm willing to help with PR.
The text was updated successfully, but these errors were encountered:
Right now I'm manually changing problematic deps.jl, relying on a enviroment variable JL_STATIC (my own definition) beacuse I don't know how to branch in case the file is being statically compilled for deployment. I'm also negotiating in PackageCompiller #153.
As a workaround for now I'm now using this deps.jl modification, and also you have to set ENV["JL_STATIC"]=="true"
## This file autogenerated by BinaryProvider.write_deps_file().
...
if isdefined((@static VERSION < v"0.7.0-DEV.484" ? current_module() : @__MODULE__), :Compat)
import Compat.Libdl
elseif VERSION >= v"0.7.0-DEV.3382"
import Libdl
end
const libRmath = ENV["JL_STATIC"]=="true" ? "libRmath-julia.dll" : joinpath(dirname(@__FILE__), "usr\\bin\\libRmath-julia.dll")
function check_deps()
global libRmath
if Libdl.dlopen_e(libRmath) in (C_NULL, nothing)
error("$(libRmath) cannot be opened, Please re-run Pkg.build(\"Rmath\"), and restart Julia.")
end
end
From Discourse and moved from BinaryBuilder issue
I’m trying to deploy a DLL compiled with latest PackageCompiler.jl 1 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 a static compilation point of view) dll location using a common construct, e.g.
const libddierckx = joinpath(dirname(@FILE), "usr\bin\libddierckx.dll")
All of them have the deps.jl generated by BB/BP with assumption their location is an absolute path. We should mitigate these hard-coded paths so that the libs (DLLs) load from one directory (the same where libjulia.dll etc. live) for static compilation? Or, if the library not found in the expected location, let libdl locate the DLL and try to use it?
The problem is, also whenever I run
pkg"gc"
then there is a 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 a PR but I don’t know where to start or if this is a known bug, backlog issue or strategic core-dev decision. I' ve read the BB roadmap but no mention of static compilation/deployment has been discussed there.Thank you for any workaround suggestion and any hint how this might get solved - I'm willing to help with PR.
The text was updated successfully, but these errors were encountered: