Skip to content

Fix build on OpenBSD #20

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix build on OpenBSD #20

wants to merge 1 commit into from

Conversation

tobhe
Copy link

@tobhe tobhe commented Mar 1, 2025

As explained in the commit OpenBSD seems to version the SONAME differently.

This patch just adds the OpenBSD one as the last of the possible matching options instead of using conditional compilation, but I guess that is the simpler solution in this case.
Happy to solve this differently if anyone has a better idea.

@tobhe
Copy link
Author

tobhe commented Mar 5, 2025

I thought some more about this and have come to the conclusion that I might be trying to fix this in the wrong layer. If dlib uses dlopen internally then libxkbcommon.so SHOULD find libxkbcommon.so.3.0 afaiu.

I'll do some further research to see what's going wrong here.

@kchibisov
Copy link
Member

Usually there should be a symlink from .so.0 to a version of the library that is being used. For example, on linux, it's usually .so and .so.0 are being symlinked to an actual thing, like .so.0 -> .so.0.8.0.

Like that's also the reason the libs are always like that, and you'd see them that way in a lot of libs, not just in xkbcommon-dl. The pattern of symlinking that way is very common.

Though, I'm not familiar with .so machinery much.

@tobhe
Copy link
Author

tobhe commented Mar 17, 2025

Right, but there is no symlink for libxkbcommon on OpenBSD. Instead dlopen(3) itself handles the version lookup automatically.

From https://man.openbsd.org/dlopen:

When a shared library is specified without a version or with a partial version, the same library search rules apply that are used for “intrinsic” shared library searches. A null pointer supplied for path will return a special handle that behaves the same as the RTLD_DEFAULT special handle.

I did some research to compare with glibc dlopen and this behavior indeed seems to be OpenBSD specific. Both implement some finding logic when only the file name (without leading path) are passed, only OpenBSD actually automatically completes the version number too.

For xkbcommon-dl that means if open_with_sonames() directly mapped to dlopen(3) it would still work with libxkbcommon.so passed as second argument but I guess it doesn't actually do that. Will need to dig deeper to learn what exactly it does.

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

Successfully merging this pull request may close these issues.

2 participants