libxcb not found on OpenBSD 7.4 #895
Comments
Heh. X11R6 was released in 1994 and X11R7 in something like 2013. I guess this just a change "let's not change the version number in this path since it would break too much stuff". And now we have this inconsistency. And apparently not even the dynamic loader's default search path can paper over this (I assume - I saw something like that in #785). Fun. Not.
Yay. And in #785 I concluded exactly the opposite. 🙈
https://github.com/openbsd/xenocara/blob/a812a0d861ff67f4c3dbd13f0753738a2bfe5990/lib/libxcb/libxcb/shlib_version seems relevant. No idea what this means, but it says They seem to have invented their own, arbitrary versioning? The update to libxcb 1.6 switches from Since I don't really understand this: @afh Do you want to send a PR that works for you? I'd just trust you on this. ...but I don't actually know what the PR should look like. If we just hardcode |
|
Thank you for the quick response, @psychon, much appreciated! Your findings regarding the OpenBSD specific libxcb Reading the OpenBSD and NetBSD manpage for dlopen(3) and doing a quick investigation first using C and dlopen and then using Rust and libloading (see below) it appears that using "just the name of the shared library itself", i.e. Excerpt from the OpenBSD and NetBSD manpage for dlopen(3)Quoting from OpenBSD dlopen(3) (with added emphasis): The path parameter can be specified as either an absolute pathname to a shared library or just the name of the shared library itself.[...] When just a shared library is specified, the same paths will be searched that are used for “intrinsic” shared library searches. Shared libraries take the following form: Quoting from NetBSD dlopen(3) (with added emphasis): The dlopen() function takes the name of a shared object as the first argument. The path argument can be specified as either an absolute pathname to a shared object or just the name of the shared object itself. [...] When just a shared object name is specified, the same search rules apply that are used for ``intrinsic'' shared object searches. (see ld.elf_so(1)) Investigation for shared library loading with C and dlopen(3) on OpenBSDint main (int argc, char* argv[]) {
for (int i = 1; i < argc; i++) {
const char* libname = argv[i];
void* handle = dlopen(libname, RTLD_LAZY);
if (handle == NULL) {
printf("Unable to dynamically load %s\n", libname);
} else {
printf("%s loaded at %p\n", libname, handle);
dlclose(handle);
}
}
exit(EXIT_SUCCESS);
}% ./dlopen-test /usr/X11R7/lib/libxcb.so.2 /usr/X11R6/lib/libxcb.so.4.1 /usr/X11R6/lib/libxcb.so.4 /usr/X11R6/lib/libxcb.so libxcb.so.4.1 libxcb.so.4 libxcb.so libxcb.so.1 libxcb.so.2
Unable to dynamically load /usr/X11R7/lib/libxcb.so.2
/usr/X11R6/lib/libxcb.so.4.1 loaded at 0x65e33fa0800
/usr/X11R6/lib/libxcb.so.4 loaded at 0x65e33fa0000
/usr/X11R6/lib/libxcb.so loaded at 0x65e3a5a5800
libxcb.so.4.1 loaded at 0x65ebba2d800
libxcb.so.4 loaded at 0x65e3a5a5800
libxcb.so loaded at 0x65e49bb8000
Unable to dynamically load libxcb.so.1
Unable to dynamically load libxcb.so.2Investigation for shared library loading with Rust and libloading on OpenBSD// I'm rather unfamiliar with Rust programming,
// so hopefully the snippet below does not cause too
// much pain while reading. Happy to hear helpful comments :)
use std::env;
fn main() {
let args: Vec<_> = env::args().collect();
for arg in &args[1..] {
print!("Trying to load {}: ", arg);
unsafe {
let libname = arg;
let lib = libloading::Library::new(libname)
.map_err(|e| println!("failed due to: {}", e));
match lib {
Ok(_) => { println!("success!"); }
Err(_) => { }
}
}
}
}% clear;cargo run -- /usr/X11R7/lib/libxcb.so.2 /usr/X11R6/lib/libxcb.so.4.1 /usr/X11R6/lib/libxcb.so.4 /usr/X11R6/lib/libxcb.so libxcb.so.4.1 libxcb.so.4 libxcb.so libxcb.so.1 libxcb.so.2
Trying to load /usr/X11R7/lib/libxcb.so.2: failed due to: File not found
Trying to load /usr/X11R6/lib/libxcb.so.4.1: success!
Trying to load /usr/X11R6/lib/libxcb.so.4: success!
Trying to load /usr/X11R6/lib/libxcb.so: success!
Trying to load libxcb.so.4.1: success!
Trying to load libxcb.so.4: success!
Trying to load libxcb.so: success!
Trying to load libxcb.so.1: failed due to: File not found
Trying to load libxcb.so.2: failed due to: File not found@psychon Are the code snippets from the investigation enough proof for you or would you prefer an actual test with and within x11rb? |
|
Can you post the output of |
|
I googled a bit around and ended up looking at https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/. I now have to do some guessing. My first guess was "readelf -d bin/lxterminal" (no RPATH, no RUNPATH, just NEEDED entries)readelf -d lib/libcairo.so.13.3 |
|
Ah, I found the binary package containing libxcb. It is https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/xbase74.tgz. And the SONAME is really just readelf -d usr/X11R6/lib/libxcb.so.4.1Anyway, I guess this means OpenBSD affords to rebuild everything on new xcb releases and does not offer any kind of API stability.
I haven't figured out where that Urgh... |
|
I found the The However, `xcb.pc` just mentions `-lxcb` without an extension (but it does mention `-L/usr/X11R6/lib`). |
|
Sorry for the monologe. Here is another entry: I asked
According to this random person there is no Dunno how this matches with @afh having such a file. Hm.... actually... @afh Can you check whether you really have a file called |
In commit 53de935 I fixed the dl-libxcb feature not finding libxcb.so on NetBSD and just assumed that this also fixes things on OpenBSD since I found some similarities. However, it turns out that OpenBSD ignores libtool's SONAME handling and just rolls its own. However, we do not really have to care much. Here, loading "libxcb.so" does the right thing. Not because there is actually a file with this name, but since the dynamic linker does some magic when it gets a request to load a library without providing version information. Thus, this commit changes the code to just load "libxcb.so" on OpenBSD. With that, I got thinking. On untested systems, we do not really know which SONAME to use. And we now have evidence that somehow just letting the OS do some magic is the best option. Thus, this commit changes the code to load "libxcb.so" on all systems except for Linux (where this would e.g. require libxcb1-dev to be installed on Debian) and NetBSD (where we have a working version that I do not want to break). Fixes: #895 Signed-off-by: Uli Schlachter <[email protected]>
|
I actually digged into the search code of OpenBSD's dynamic linker. With that insight, I am totally fine with just using |
|
First of all thanks @psychon and @eduardosm for putting all the work into this issue, very much appreciated! 🙏 Here's the output of readelf as requested:
|
Ah, okay. I took a look at the features winit uses and would suggest For extra brownie points, you could run the above command with current x11rb master and also with an older version (to make sure it really breaks there). |
|
Thanks for the suggestion. When running the warning: some crates are on edition 2021 which defaults to `resolver = "2"`, but virtual workspaces default to `resolver = "1"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
Compiling x11rb-protocol v0.12.0 (/home/afh/Developer/x11rb/x11rb-protocol)
Compiling x11rb v0.12.0 (/home/afh/Developer/x11rb/x11rb)
error: could not compile `x11rb-protocol` (lib)
Caused by:
process didn't exit successfully: `rustc --crate-name x11rb_protocol --edition=2021 x11rb-protocol/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="all-extensions"' --cfg 'feature="composite"' --cfg 'feature="damage"' --cfg 'feature="dbe"' --cfg 'feature="default"' --cfg 'feature="dpms"' --cfg 'feature="dri2"' --cfg 'feature="dri3"' --cfg 'feature="extra-traits"' --cfg 'feature="glx"' --cfg 'feature="present"' --cfg 'feature="randr"' --cfg 'feature="record"' --cfg 'feature="render"' --cfg 'feature="request-parsing"' --cfg 'feature="res"' --cfg 'feature="resource_manager"' --cfg 'feature="screensaver"' --cfg 'feature="shape"' --cfg 'feature="shm"' --cfg 'feature="std"' --cfg 'feature="sync"' --cfg 'feature="xevie"' --cfg 'feature="xf86dri"' --cfg 'feature="xf86vidmode"' --cfg 'feature="xfixes"' --cfg 'feature="xinerama"' --cfg 'feature="xinput"' --cfg 'feature="xkb"' --cfg 'feature="xprint"' --cfg 'feature="xselinux"' --cfg 'feature="xtest"' --cfg 'feature="xv"' --cfg 'feature="xvmc"' -C metadata=511b0427c01f03fc -C extra-filename=-511b0427c01f03fc --out-dir /home/afh/Developer/x11rb/target/debug/deps -C incremental=/home/afh/Developer/x11rb/target/debug/incremental -L dependency=/home/afh/Developer/x11rb/target/debug/deps` (signal: 11, SIGSEGV: invalid memory reference) |
|
Uhm. Sorry, I have no idea either. That seems to be the rust compiler crashing...?!? |
|
Thanks for comment, @psychon. I'll see what can I find… |
1️⃣ The changes introduced with #788 to fix #785 do not work for OpenBSD 7.4 (and likely previous versions) as the path for X11 window system files on OpenBSD is
/usr/X11R6(see OpenBSD hier(7)) and differs from NetBSD's path, i.e./usr/X11R7(see NetBSD hier(7)).2️⃣ Furthermore the filename for libxcb on OpenBSD 7.4 is
libxcb.so.4.1rather thanlibxcb.so.1orlibxcb.so.2. I don't know where the.4.1suffix on OpenBSD comes from, but will keep investigating.A read-only mirror of the sources for the OpenBSD X11 window system are available at openbsd/xenocara and may provide further insight.
The text was updated successfully, but these errors were encountered: