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