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(a)redhat.com>
>>>> ---
>>>> 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=167390f05564e0a4d3fcb43293...
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
--
|: