victor-shepardson
commented
2 years ago I notice that when using PackageCompiler with the 1.7.1 release build of Julia, libjulia.dylib and the entry point built by PackageCompiler (in my case libscjulia.dylib) end up in a lib directory, but everything else e.g. libjulia-internal.dylib are in lib/julia. Whereas with the debug build, everything is together in lib. However, I made sure to add both as rpaths when building my plugin:
$ otool -L build/JuliaUGen_scsynth.scx
build/JuliaUGen_scsynth.scx:
@rpath/libjulia.dylib (compatibility version 1.0.0, current version 1.7.1)
@rpath/libscjulia.0.1.0.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
$ otool -l build/JuliaUGen_scsynth.scx | grep RPATH -A 2
cmd LC_RPATH
cmdsize 56
path @loader_path/../SCJulia/build/scjulia/lib/ (offset 12)
--
cmd LC_RPATH
cmdsize 64
path @loader_path/../SCJulia/build/scjulia/lib/julia/ (offset 12)So I can't see how this difference would cause the failure.
I also notice that libscsynth uses @executable_path unlike my .scx plugin and the other Julia .dylibs:
$ otool -L SCJulia/build/scjulia/lib/libscjulia.dylib
SCJulia/build/scjulia/lib/libscjulia.dylib:
@rpath/libscjulia.0.1.0.dylib (compatibility version 0.0.0, current version 0.1.0)
@rpath/libjulia-debug.dylib (compatibility version 1.0.0, current version 1.7.1)
@rpath/libjulia-internal-debug.dylib (compatibility version 1.0.0, current version 1.7.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
$ otool -l SCJulia/build/scjulia/lib/libscjulia.dylib | grep RPATH -A 2
cmd LC_RPATH
cmdsize 32
path @executable_path (offset 12)
--
cmd LC_RPATH
cmdsize 40
path @executable_path/julia (offset 12)
$ otool -l SCJulia/build/scjulia/lib/libjulia-internal-debug.dylib | grep RPATH -A 2
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)this is true for both debug and release Julia. AFAICT the dynamic linker wouldn't find libjulia-internal-debug.dylib using @executable_path, which would point to the location of scsynth which loads JuliaUGen_scsynth.scx which loads libscjulia.dylib which loads libjulia*.dylib.
If I use install_name_tool to change @executable_path to @loader_path here, nothing changes. debug still works and release still fails.
man dyld says:
The run path stack is built from the LC_RPATH load commands in the dependency chain that lead to the current dylib load.
so I think it's the use of @loader_path in JuliaUGen.scx which is actually enabling libscjulia to find further dependencies?
Hi, I'm trying to use PackageCompiler to build a shared library which I can link into a relocatable plugin for a complex piece of C++ software, specifically, scsynth (https://supercollider.github.io/).
OS: macOS 10.14.6 (x86_64-apple-darwin18.7.0) cpp: Apple LLVM version 10.0.1 (clang-1001.0.46.4) Julia: 1.7.1 .app release / 1.7.1 debug built locally with
git checkout v1.7.1; make debugCurrently my plugin fails during the
init_juliacall, which is in a class constructor not inmainsince this is a plugin.here's the backtrace:
looks like maybe somewhere in here: https://github.com/JuliaLang/PackageCompiler.jl/blob/v2.0.4/src/julia_init.c#L27-L38 ?
I'm not sure if this will turn out to be a PackageCompiler issue, scsynth issue or user error:
init_juliacode in a minimal C++ program (https://github.com/victor-shepardson/sc-julia/blob/master/plugins/JuliaUGen/test.cpp) works as expected, so the scsynth environment may be relevant.code is here: https://github.com/victor-shepardson/sc-julia