On Wed, Mar 09, 2022 at 01:53:49PM +0100, Michal Prívozník wrote: > On 3/9/22 13:25, Daniel P. Berrangé wrote: > > On Wed, Mar 09, 2022 at 01:14:39PM +0100, Michal Prívozník wrote: > >> On 3/9/22 11:36, Daniel P. Berrangé wrote: > >>> On Wed, Mar 09, 2022 at 11:27:22AM +0100, Martin Kletzander wrote: > >>>> A bit of effort by me and Michal helped make this the case, and it helped us > >>>> uncover some potential issues. I am not documenting it as supported or adding > >>>> an Alpine container into the CI, but since there were some distribution bugs > >>>> mentioning libvirt issues I thing it would be nice of us to notify those > >>>> distribution maintainers that read our release news. > >>>> > >>>> Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> > >>>> --- > >>>> NEWS.rst | 3 +++ > >>>> 1 file changed, 3 insertions(+) > >>>> > >>>> diff --git a/NEWS.rst b/NEWS.rst > >>>> index a5b6106bc2c2..f0270b9bb159 100644 > >>>> --- a/NEWS.rst > >>>> +++ b/NEWS.rst > >>>> @@ -21,6 +21,9 @@ v8.2.0 (unreleased) > >>>> > >>>> * **Bug fixes** > >>>> > >>>> + * Both build and tests should now pass on Alpine Linux or any other > >>>> + distribution with musl libc. > >>> > >>> IMHO even though you don't say it explicitly, anyone reading this > >>> will interpret it at meaning libvirt is expected to work with > >>> musl, which is misleading > >> > >> With everything turning into a container nowadays, I believe it's time > >> to revisit our decision of supported platforms. Or even if we don't want > >> to support Alpine, that's fine, but perhaps have it CI, allow it to fail > >> (just like we're doing for rawhide/sid) and see if we still compile? The > >> benefit would be more portable code (like Martin's patches from past > >> week demonstrate). > > > > I'm not saying we shouldn't support Alpine, just that I don't believe > > it works today, and making it work is not an quick & easy change at > > all. > > > > Unlike the other C libraries we deal with, musl doesn't allow you to > > use malloc after fork in a threaded application, and will deadlock. > > While that used to be true, it's not like that anymore: > > https://git.musl-libc.org/cgit/musl/commit/?id=167390f05564e0a4d3fcb4329377fd7743267560 Ah well that's excellent, glad to see sanity prevailed on allowing malloc across fork and unlocking mutexes in child that were locked in the parent. With 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 :|
