Use a dynamic library instead about x11-rs HOT 17 CLOSED

I like the idea of compiling a single binary that works with multiple system configurations! I'm not sure how I feel about this being the default behavior, but it would be easy to implement in the form of a feature. Maybe after I play around with it a bit, I'll change my mind and just make it the default anyway. Would it be sufficient to just search /usr/lib and /usr/local/lib for the needed libraries?

from x11-rs.

We can use dylib until std::dynamic_lib is stable.

from x11-rs.

I was thinking of using the shared_library library I wrote.
It provides a macro named shared_library! which is similar to export {} blocks and makes the transition easier (it would also make it easier to revert the changes if wanted).
Example here: https://github.com/tomaka/glutin/blob/master/src/api/caca/ffi.rs

from x11-rs.

I can get started on this as soon as I get home.

from x11-rs.

I thought about working on it myself, but if you do it that would be awesome!

Note that you probably need to add an attribute like #![recursion_limit="200"], or you will reach the recursion limit.

from x11-rs.

I've run into a problem. The shared_library macro doesn't seem to like variadic C functions like XCreateIC. I would comment them out until finding a workaround, but IIRC, glutin uses this function in particular.

from x11-rs.

Arg. I'm aware of this limitation, but I thought that X11 didn't have any variadic function.

from x11-rs.

I may have found a solution, but it's not quite as pretty as I had hoped. I wrote a macro with two patterns: one that takes the usual list of functions, and one that takes a list of functions followed by variadic: and a list of variadic functions, omitting the ellipses in the pattern to make the compiler happy.

  pub fn XWriteBitmapFile (_7: *mut Display, _6: *const c_char, _5: c_ulong, _4: c_uint, _3: c_uint, _2: c_int, _1: c_int) -> c_int,
  pub fn XXorRegion (_3: Region, _2: Region, _1: Region) -> c_int,
variadic:
  pub fn XCreateIC (_1: XIM) -> XIC,
  pub fn XCreateOC (_1: XOM) -> XFontSet,

I'm still working out a bug that's preventing it from compiling, but I should have a test working soon. Should I apply this to shared_library and submit a pull request?

from x11-rs.

Should I apply this to shared_library and submit a pull request?

That would be nice!

from x11-rs.

x11-rs now supports dynamic linking with a temporary macro when the dynamic feature is enabled. This temporary macro will be updated once I can wrap my head around the recursiveness of shared_library!.

from x11-rs.

Example usage:

use x11::xlib::Xlib;

fn do_something_but_not_anything_useful_just_as_an_example () {
  let xlib = Xlib::open().unwrap();
  let display = (xlib.XOpenDisplay)(null());
  (xlib.XCloseDisplay)(display);
}

from x11-rs.

Note that this is a bad usage of Cargo features.
Cargo features are not flags. If a code depends on x11 without dynamic, then adds a dependency on glutin, then x11 will get compiled with the dynamic feature and break the code.

from x11-rs.

Fixed so extern blocks are not removed. The compiler only tries to link the functions if they are actually called, so this shouldn't cause problems. If this turns out to be wrong, another possible solution is to split the dynamic interface into another crate (but still in to same repo and from mostly the same sources).

from x11-rs.

The compiler only tries to link the functions if they are actually called, so this shouldn't cause problems.

Are you sure that it doesn't pass -lx11 to the linker?

from x11-rs.

The build script uses pkg-config, so it might still pass -lX11 if x11-rs was compiled on a system where pkg-config detected Xlib. Because of this, it might not work to have the old API and the dynamic API coexist in one crate unless I'm forgetting another option. I can't remove the old API because it appears that it will soon be used by servo. If you're okay with it, I'll add another crate for the dynamic API. They'll exist in the same repo and use the same sources for bindings, but different sources for internals (such as the x11_link macro).

from x11-rs.

I have the split working in a separate branch (dl_split). If you're okay with the changes, I'll submit a pull request to glutin. The only usage change would be using crate x11_dl instead of x11.

from x11-rs.

Sure, as long as you publish it on crates.io

from x11-rs.