Restore the version information for libjulia.dylib

[fingolfin]

Fixes #38782

This is a bit of a hack, but seems to work on my Mac, but I have not yet tested this on other operating systems. The main question is whether the other non-empty value for JLIBLDFLAGS , namely -Wl,-Bsymbolic-functions, which is used on Linux systems if the linker there supports it. I have no idea what this does; in particular, I don't know if setting it here ...

1. does not matter,
2. is incorrect,
3. fixes another potential bug.

CC @staticfloat

[fingolfin]

Note that even with this, there are troubles:

[ 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

[thofma]

Needs the backport label.

[staticfloat]

@vtjnash do you have any insight into whether -Bsymbolic-functions would interfere with our trampoline symbols?

[vtjnash]

Why not -Bsymbolic? Though I think this may be the same as the protected visibility?

[staticfloat]

It's not that I want to add these linker commands, it's that they get added as a side-effect of the other flags that are added to libjulia.so through JLIBLDFLAGS.

[fingolfin]

Besides all that, even with this PR, I can't use various JLLs which access libjulia.dylib (linked at build time via libjulia_jll) because references to e.g. jl_cstr_to_string or jl_n_threads cannot be resolved even though they are marked as JL_DLLEXPORT. What's up with that?

This affects e.g. CxxWrap.jl which as a result is broken for me in 1.6 / 1.7 (CC @barche)

[fingolfin]

Of course the answer to that might be to create a libjulia_jll 1.6, and rebuild all JLLs using libjulia_jll to also have a 1.6 variant. But it'd be much nicer if one could use the same binaries for 1.5 and 1.6...

[barche]

I don't really understand what changed here, but from Julia 1.6 on we can have julia_version in the platform, so having a libjulia for each of those seems the cleanest solution to me? Maybe on the libjulia dependencies we couls have an expand_julia_versions function that works like the expand_cxx_abis in BinaryBuilder?