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

Dynamic library loader: search in -L directories before default ones #13069

Merged
merged 2 commits into from
Feb 14, 2023

Conversation

HertzDevil
Copy link
Contributor

@HertzDevil HertzDevil commented Feb 13, 2023

Fixes #12214.

The link flags for OpenSSL and libcrypto already include the explicit directory returned by pkg-config, because at one point we wanted to detect OpenSSL 1.0.2 and enable its new features if found. The problem is that our loader always tries the default library paths before ones specified via the -Ls from the link flags, and the first entry is /usr/lib, which means the system libraries are always searched first, and /usr/lib/libcrypto.dylib is specifically made to abort any application that attempts to load it.

That failure also happens with a plain dlopen, by the way:

LibC.dlopen("/usr/lib/libcrypto.dylib", LibC::RTLD_LAZY | LibC::RTLD_GLOBAL)
LibC.dlopen("libcrypto.dylib", LibC::RTLD_LAZY | LibC::RTLD_GLOBAL)

The MSVC loader already searches in the directories specified via /LIBPATH before the default ones.

src/compiler/crystal/loader/unix.cr Outdated Show resolved Hide resolved
@straight-shoota straight-shoota added this to the 1.8.0 milestone Feb 13, 2023
@straight-shoota straight-shoota merged commit c9b90e2 into crystal-lang:master Feb 14, 2023
@HertzDevil HertzDevil deleted the bug/loader-dir-order branch February 15, 2023 11:29
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.

interpreter: loading libcrypto in an unsafe way
2 participants