Re: [libvirt PATCH] news: Document that we build with musl

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(a)redhat.com&gt; >>> --- >>> 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.