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 :|
