Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add workaround for musl lack of SONAME support #34

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

staticfloat
Copy link
Member

Because musl doesn't pay attention to SONAMEs, we cannot load JLLs
with transient dependencies because musl always tries to do an
environment search for dependencies, even if they're already loaded. We
work around this by manually altering the dso structures that musl
maintains for each loaded library, making it look like the library was
loaded by a previous environment search instead of by loading directly
via full path.

@@ -92,3 +92,24 @@ function get_julia_libpaths()
end
return JULIA_LIBDIRS
end

@static if VERSION >= v"1.6.0" && libc(HostPlatform()) == "musl"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point we can do #31 as well? 🙃

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, sure. We can do both for now.

@giordano
Copy link
Member

CC: @jpsamaroo

Because `musl` doesn't pay attention to SONAMEs, we cannot load JLLs
with transient dependencies because `musl` always tries to do an
environment search for dependencies, even if they're already loaded.  We
work around this by manually altering the `dso` structures that `musl`
maintains for each loaded library, making it look like the library was
loaded by a previous environment search instead of by loading directly
via full path.
Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
Project.toml Show resolved Hide resolved
@staticfloat
Copy link
Member Author

With this I can now do:

$ docker run -ti julia:alpine
(@v1.6) pkg> add JLLWrappers#sf/musl_workaround
(@v1.6) pkg> add Tar_jll
julia> using Tar_jll

@staticfloat
Copy link
Member Author

@vtjnash I'm pinging you because I think we arguably want to do this for all dlopen()'s in Julia. What do you think?

@jpsamaroo
Copy link

This is a pretty hilarious hack... do we know if it has a potential to break in the future?

@giordano
Copy link
Member

A few minutes ago I wrote this on Slack to Elliot 😛

Screenshot_20210818_021812

@staticfloat
Copy link
Member Author

Just for the record, this only works on Alpine 3.11+, before that the layout is different, so unless I add some code to deal with that, we will indeed have issues around that.

@staticfloat staticfloat force-pushed the sf/musl_workaround branch 4 times, most recently from 9fbbe39 to f57d071 Compare August 19, 2021 22:13
@staticfloat
Copy link
Member Author

Okay, this now passes testing on all versions of Alpine from 3.6+. I defined layouts for versions of musl earlier than that, but Alpine backports lots of patches that change the layout of the DSO object on those earlier versions (but still identifies the musl version as the old version), so it's a losing battle to try to support those old versions. God willing nobody is using such old versions anyway.

This is an annoying amount of copypasta. @vtjnash what are your thoughts on this? Is this a doomed approach? Should we instead have Julia notice it's running on musl, then re-invoke itself with a custom interpreter that has Julian's patch applied?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants