On Sat, Aug 22, 2020 at 05:03:45PM -0700, Scott Shambarger wrote:
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...
I don't think we want to keep compatibility with any libtool quirks. We
should do the right thing for the platform, and I think that means using
the platform native suffix for shared library modles correctly.
> Also, libvirtd would probably work on Cygwin or Midipix, which would
> use DLL files...
We don't support Cygwin, only Mingw
>
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?).
We don't support any use of 3rd party modules.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|