Skip to content

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