To avoid the X/Y problem I’ll explain my use case:
I need to load a dynamic lib in Emacs, which has become possible in Emacs 25.
However, it refuses to load a
.dylib file and will accept only an
.so, even on OS X.
There is a variable that holds the accepted extensions but modifying that has no actual effect on Emacs’ pickiness.
Right now I work around the problem by copying the
.dylib produced by Cargo/RustC to the same stem but with
.so as extension, and Emacs swallows that without complaints (so both dylib production and consumption are currently on OS X). But it turns my compilation CLI line from a cute little
cargo build into a Lovecraftian
cargo build && cp target/debug/libmy_module.dylib target/debug/libmy_module.so. Which of course is scriptable, but this seems to me something Cargo somehow should be able to produce, with the right arguments.
Now the ideal solution is of course for Emacs to start accepting
.dylib files on OS X (and if it doesn’t do so already,
.dll on Windows). But given that I can’t easily hack that into Emacs, I’d like to be able to produce an
.so file directly.
And no, I happen to not be using GCC. I’m trying to oxidize C code in this case