On 2020-08-22 15:45, Neal Gompa wrote:
Shouldn't it be fixed the other way? That is, it should know about DLL, SO, or DYLIB extensions depending on the platform...
Well, there's a myriad of discussions regarding this on projects from glib to hexchat (and I read quite a few of them :)... basically, libtool has used .so for modules ("bundles" on MacOS) for 14 years, as does MacPorts and Homebrew -- it might just be easier to follow the crowd...
Also, libvirtd would probably work on Cygwin or Midipix, which would use DLL files...
There's more complexity there... since windows doesn't add the "lib" prefix, driver.c would need to handle that edge-case as well...
libvirtd has historically used ".so" on MacOS (via libtool). Any "externally" installed drivers would break if that changed (are there any?).
I'd be game to work on a patch that uses the whatever meson does, but I don't think it currently has a specific config for the suffix used for loadable modules (which, on MacOS should really be ".bundle", but is currently ".dylib" - just to be even more confused :).
Thoughts? Scott
