Disable DL_LOAD_PATH prepending for @-paths on Darwin

[staticfloat]

Many thanks to Randy Rucker from Apple for pointing out that we were
technically relying on undefined behavior in dyld for loading things
via jl_dlopen("@loader_path/@rpath/libfoo.dylib"), due to the
composition of dlopen("@rpath/libfoo.dylib") in our Julia code, and
the DL_LOAD_PATH prepending we do in jl_load_dynamic_library().

This PR uses a slightly modified version of a patch emailed to me by
Randy, and should solve
JuliaLang/Downloads.jl#149 on macOS Monterey
where the undefined behavior in dyld has changed.

[staticfloat]

Confirmed to fix JuliaLang/Downloads.jl#149

[vtjnash]

Why is this code trying to handle full paths (with /) in them anyways?

Also, seems like we have special handling here for @executable_path that is now getting dropped on macOS?

[staticfloat]

Also, seems like we have special handling here for @executable_path that is now getting dropped on macOS?

Ironically, the @executable_path stuff is actually for everything other than macOS, since macOS supports that natively. I agree it's confusing though; what do you suggest? The @executable_path stuff is to emulate that functionality on Windows and other platforms that don't have a way to load something with a relative path from the executable itself.

Why is this code trying to handle full paths (with /) in them anyways?

I don't quite understand what you're asking.

[vtjnash]

I don't understand why this code is combining a/b with Dl_LOAD_PATH, and not just when given b. It is common for the shell, for example, to only search if given only a name and not a path.

[staticfloat]

Aha, I see what you mean. Yeah, that's not necessarily useful.

I think we can probably refactor this to be a three-step process:

1. Translate @executable_path/-style modnames to an absolute path.
2. Do abspath and is_atpath detection (the latter still macOS-only)
3. Enter DL_LOAD_PATH loop.

This way, we'll have consistent handling across platforms as much as possible, and we cut down on unnecessary jl_load_dynamic_library() calls.

[vtjnash]

I agree

[staticfloat]

Looking into this a bit deeper, I see that we are actually transforming the entries of DL_LOAD_PATH, not modname. E.g. we are allowing for DL_LOAD_PATH to contain @executable_path/../lib/, and then prepend it to all entries.

I had forgotten that that was how I designed this, and I'm not at all sure that this is precisely what we want. I don't think we're actively using this feature yet, so we can still change it if we want to. This was done to serve these changes from my JLL stdlibs PR, where I wanted to get Base able to dlopen("libpcre2-8") when that file lived in some very specific location. Looking back on it now, my gut says that the "right" way to do this would be for us to dlopen("@executable_path/../whatever"), but the reason we aren't doing that is because we just do ccall) without any explicit dlopen() on libpcre due to us needing libpcre so early on that we don't have access to niceties like joinpath(). We could, of course, hardcode a specific dlopen() instead. I'm undecided.