JLLs built against libjulia_jll 1.5 are unusable in Julia 1.6 on macOS (breaks CxxWrap)

[fingolfin]

Thanks for merging PR #38829. However, there are still issues. Currently even with that fix, I still get this on latest Julia master:

julia> using CxxWrap
[ Info: Precompiling CxxWrap [1f15a43c-97ca-5a2a-ae31-89f07a497df4]
dyld: lazy symbol binding failed: Symbol not found: _jl_cstr_to_string
  Referenced from: /Users/mhorn/.julia/artifacts/0eb6ffcbe0cde10007a2678013611da80643b728/lib/libcxxwrap_julia.0.8.2.dylib
  Expected in: /Users/mhorn/Projekte/Julia/julia.master/usr/bin/../lib/libjulia.dylib

dyld: Symbol not found: _jl_cstr_to_string
  Referenced from: /Users/mhorn/.julia/artifacts/0eb6ffcbe0cde10007a2678013611da80643b728/lib/libcxxwrap_julia.0.8.2.dylib
  Expected in: /Users/mhorn/Projekte/Julia/julia.master/usr/bin/../lib/libjulia.dylib

or this:

julia> using GAP
[ Info: Precompiling GAP [c863536a-3901-11e9-33e7-d5cd0df7b904]
ERROR: LoadError: InitError: could not load library "/Users/mhorn/.julia/artifacts/50127818ecdc20c9948526407e04ae1b124e7bf1/lib/libgap.0.dylib"
dlopen(/Users/mhorn/.julia/artifacts/50127818ecdc20c9948526407e04ae1b124e7bf1/lib/libgap.0.dylib, 1): Symbol not found: _jl_n_threads
  Referenced from: /Users/mhorn/.julia/artifacts/50127818ecdc20c9948526407e04ae1b124e7bf1/lib/libgap.0.dylib
  Expected in: /Users/mhorn/Projekte/Julia/julia.master/usr/bin/../lib/libjulia.dylib
 in /Users/mhorn/.julia/artifacts/50127818ecdc20c9948526407e04ae1b124e7bf1/lib/libgap.0.dylib

Note that both examples work on Linux.

Both symbols are marked as JL_DLLEXPORT:

$ git grep 'JL_DLLEXPORT.*jl_cstr_to_string'
src/array.c:JL_DLLEXPORT jl_value_t *jl_cstr_to_string(const char *str)
src/julia.h:JL_DLLEXPORT jl_value_t *jl_cstr_to_string(const char *str);
$ git grep 'JL_DLLEXPORT.*jl_n_threads'
src/threading.c:JL_DLLEXPORT int jl_n_threads;
src/threading.h:extern JL_DLLEXPORT int jl_n_threads;   /* # threads we're actually using */

Looking a bit closer, we see jl_n_threads is missing in libjulia.dylib but present in libjulia-internal.dylib:

$ nm usr/lib/libjulia.dylib | fgrep jl_n_threads
$ nm usr/lib/libjulia-internal.dylib | fgrep jl_n_threads
000000000032b948 S _jl_n_threads

And jl_cstr_to_string is there in the internal copy, but in the public library, it is missing the leading underscore:

$ nm usr/lib/libjulia.dylib | fgrep jl_cstr_to_string
0000000000010720 s _jl_cstr_to_string_addr
0000000000001e61 T jl_cstr_to_string
$ nm usr/lib/libjulia-internal.dylib | fgrep jl_cstr_to_string
00000000000a2aa0 T _jl_cstr_to_string

Indeed, it seems all the re-exported function symbols miss the leading underscore.

So I think there are two separate problems here:

1. the missing underscores
2. the symbol jl_n_threads is not re-exported, despite having JL_DLLEXPORT. An oversight or intentional? If intentional, how can I replace it (basically, I just need to test if jl_n_threads > 1 -- so a getter function would do it for me.

[imciner2]

I have a fix for the exported OSX symbols in progress, but while making that I noticed a possible inconsistency with the Windows symbols. Can anyone confirm that the i686 Windows libjulia.so is also exporting the symbols correctly? If I am reading the trampoline code correctly, it is probably also broken (but I would like confirmation about that).

As for the jl_n_threads function, that isn't in the exported list for the public functions in jl_exported_funcs.inc, so it wasn't getting a trampoline function compiled. I think that currently there is no tooling to generate that file from the code, and it is simply hand generated. I will add that in my PR.

Edit: jl_n_threads is a variable, so it should actually be inside jl_exported_data.inc.

[fingolfin]

Thanks. Note that jl_n_threads is a global variable, not a function.

Would it make sense to write a script which scans for symbols with JL_DLLEXPORT and uses those to generate jl_exported_data.inc?

[fingolfin]

Unfortunately this issue persists on the release-1.6 branch, see #38938 (comment)

[staticfloat]

@fingolfin is this resolved now?

[KristofferC]

#39226 says "Fixes #38925" so I guess so.

[fingolfin]

Well it will only be truly reaolved when the backports in PR #39160 are merged. But I hope that's going to happen in any case (and rather sooner than later? I can't test against 1.6-nightly right now because of this)