Fix dl-libxcb feature on OpenBSD and NetBSD

[psychon]

Turns out that libtool uses a different logic for turning its "-version-info" into a file name on OpenBSD and NetBSD than on Linux, Darwin, and FreeBSD. On the affected BSDs, this just takes "current", which is the first argument to "-version-info". Everywhere else, the logic is "current - age".

Since libxcb uses "-version-info 2:0:1", this means that we end up with libxcb.so.2 on OpenBSD and NetBSD instead of the libxcb.so.1 that the code expects. Thus, we failed to load libxcb.

Fix this by correcting the library name on OpenBSD and NetBSD.

Fixes: #785
Signed-off-by: Uli Schlachter psychon@znc.in

---

@ids1024 Since you say you have a NetBSD VM, could you give this PR a try?

[codecov]

Codecov Report

Base: 13.70% // Head: 13.70% // No change to project coverage 👍

Coverage data is based on head (15636e9) compared to base (c8b4c9b).
Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #788   +/-   ##
=======================================
  Coverage   13.70%   13.70%           
=======================================
  Files         142      142           
  Lines      120070   120070           
=======================================
  Hits        16454    16454           
  Misses     103616   103616           

Flag	Coverage Δ
tests	13.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
x11rb/src/xcb_ffi/raw_ffi/ffi.rs	0.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ids1024]

On NetBSD this is now just showing Shared object "libxcb.so.2 not found". The library is located in /usr/X11R7/lib so presumably it isn't using the right search path.

[psychon]

Urgh. I kind of assumed this to be in the default search path. :-( I guess this means we need an absolute path.

diff --git a/x11rb/src/xcb_ffi/raw_ffi/ffi.rs b/x11rb/src/xcb_ffi/raw_ffi/ffi.rs
index 75da58c..ca2726e 100644
--- a/x11rb/src/xcb_ffi/raw_ffi/ffi.rs
+++ b/x11rb/src/xcb_ffi/raw_ffi/ffi.rs
@@ -36,9 +36,10 @@ pub(crate) mod libxcb_library {
             compile_error!("dl-libxcb feature is not supported on non-unix");
             #[cfg(all(unix, not(any(target_os = "openbsd", target_os = "netbsd"))))]
             const LIB_NAME: &str = "libxcb.so.1";
-            // libtool turns -version-info differently into SONAMES on Open and NetBSD
+            // libtool turns -version-info differently into SONAMES on Open and NetBSD.
+            // Also, the library is apparently not in the default search path, hence use a full path.
             #[cfg(any(target_os = "openbsd", target_os = "netbsd"))]
-            const LIB_NAME: &str = "libxcb.so.2";
+            const LIB_NAME: &str = "/usr/X11R7/lib/libxcb.so.2";
 
             let library = libloading::Library::new(LIB_NAME)
                 .map_err(|e| LibxcbLoadError::OpenLibError(LIB_NAME.into(), e.to_string()))?;

(The above was amended into this PR)

[eduardosm]

@ids1024 Could you run readelf -d executable, replacing executable with some executable linked to libxcb.so.2. I'm curious to know if they have an RPATH or something like that.

[ids1024]

/usr/X11R7/bin/xeyes has Library rpath [/usr/X11R7/lib]. If I install gnome-terminal it has that plus some directories in /usr/pkg/gcc10.

pkg-config --libs xcb gives -L/usr/X11R7/lib -Wl,-rpath,/usr/X11R7/lib -lxcb

[eduardosm]

Then I believe we can assume that the RPATH is part of the "stable ABI" because installing the library in a different location would be a breaking change. In that case, passing the full path to libloading would be the way to go.

[psychon]

passing the full path to libloading would be the way to go.

Does that mean I get an approve? :-)

[ids1024]

As expected, examples now run on NetBSD with dl-libxcb. I think OpenBSD should be the same but haven't tested it.

(Apparently x86_64-unknown-illumos is also a Rust Tier 2 target with host tools? I wonder where the library is there...)