rust_libloading icon indicating copy to clipboard operation
rust_libloading copied to clipboard

dlmopen support

Open SoniEx2 opened this issue 6 years ago • 9 comments

SoniEx2 avatar Dec 09 '17 13:12 SoniEx2

dlmopen seems like an awfully GNU-specific function that cannot be expressed in a manner portable between even unix targets.

I feel like it should be fine to expect people to bind this manually if they need the functionality provided by this function.

nagisa avatar Jan 02 '18 21:01 nagisa

While dlmopen is often considered a GNU extension, the concept is not GNU-specific.

For one, Windows' DLL APIs are equivalent to dlmopen. In addition to that, dlmopen is also available on SunOS/Solaris.

It would be nice if other systems adopted it, as it allows coexistence of, say, Python 2 and Python 3 in the same process space, but in the meantime we should do our best to provide it where available, and panic at runtime otherwise (just a better option than not allowing the library to compile at all, but this is up to you, obviously).

If it becomes popular enough, this should be enough to get other systems to support it, as you don't usually want your ports to just panic at runtime.

SoniEx2 avatar Jan 02 '18 22:01 SoniEx2

I still have found no indication that any other UNIX targets other than the GNU-based ones have this function available. It is not available on macOS for example.

we should do our best to provide it where available, and panic at runtime otherwise (just a better option than not allowing the library to compile at all, but this is up to you, obviously).

It would be possible to provide it under gnu target_abi cfg, but in that case it is not obvious to those using unix-specific APIs that dlmopen API is not available outside of GNU. Hmmm…

nagisa avatar Jun 17 '19 18:06 nagisa

https://docs.oracle.com/cd/E86824_01/html/E54766/dlmopen-3c.html

SoniEx2 avatar Jun 17 '19 18:06 SoniEx2

There’re methods to convert to/from raw OS primitives in 0.5.2 so you can dlmopen things manually and produce Library out of that.

nagisa avatar Jul 09 '19 00:07 nagisa

There’re methods to convert to/from raw OS primitives in 0.5.2 so you can dlmopen things manually and produce Library out of that.

I've done that in a local project... Any chance to expose some of your dlerror functionality, so that I can re-use the same mechanisms as you have if dlmopen fails?

aidancully avatar Feb 26 '21 14:02 aidancully

I wouldn't be opposed to exposing with_dlerror and a similar function for Windows in some shape or form, but some thought and changes will be necessary to make the API more suitable for pub.

nagisa avatar Feb 26 '21 16:02 nagisa

~~We've got this requirement unfortunately... :innocent: Is there viable workaround here? Can you locate how you overcome @aidancully ?~~

+        let name = CString::new(library).expect("invalid library name");
+        let pointer = unsafe { libc::dlmopen(LM_ID_NEWLM, name.as_ptr(), RTLD_LAZY | RTLD_LOCAL) };
+
+        if pointer.is_null() {
+              // I'm ignoring error here 
+        }
+
         let library = Rc::new(unsafe {
-            sys::MyLibrary::new(library)?,
+            sys::MyLibrary::from_library(Library::from(unix::Library::from_raw(pointer)))
         });

I followed what you meant. with_dlerror seems to be enough to use the API.

ileixe avatar Feb 26 '24 09:02 ileixe

I'll make with_dlerror public in https://github.com/nagisa/rust_libloading/pull/139. You should be able to write your code with proper error handling in place shortly (once I release 0.8.2)

nagisa avatar Mar 01 '24 17:03 nagisa