From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: libvirt broken in musl due to lack of utmpx implementation in musl
Date: Mon, 14 Oct 2019 08:36:31 +0200 [thread overview]
Message-ID: <20191014063631.j8FNH3i8RJw_zBbgo834fyusCkYKBHoZkM8Yzb75D_I@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-14721@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
New comment by zippy2 on void-packages repository
https://github.com/void-linux/void-packages/issues/14721#issuecomment-541519667
Comment:
> I don't know for sure if libvirt ever worked on musl since I've never tried it. But if this is the only issue there is on musl, it should have worked before the last update. Version 5.7.0 introduced the virHostGetBootTime() check and thus also stopped working on Void glibc systems. This was solved by writing a record to utmp at boot time.
>
> I'm not sure how we should deal with this. Libvirt is using POSIX functions here so they are not relying on something that generally is libc specific. Musl implements the POSIX specifications which only states that these functions shall be declared and function prototypes shall be provided, not that the functions actually have to do anything.
Wait what? Can you elaborate more please? I'm the one who wrote that code and I don't recall seeing this behaviour documented somewhere. How can one write good software when libraries are playing tricks like this? Our code is #ifdef-ed and at configure time presence of getutxid() is checked. I can put another case for linux systems that don't have the function (presumably the function will read /proc/uptime and then do some time calculations).
>
> I tried earlier to pretend that the function is not available and compile libvirtd that way but that just makes it error out with a different error.
Yes, because libvirt's philosophy is to use POSIX and be able to compile on POSIX systems. Anything that's above has to be in a separate module.
next prev parent reply other threads:[~2019-10-14 6:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 18:17 [ISSUE] " voidlinux-github
2019-09-25 18:39 ` voidlinux-github
2019-10-10 20:06 ` voidlinux-github
2019-10-11 17:08 ` voidlinux-github
2019-10-11 19:46 ` voidlinux-github
2019-10-11 20:15 ` voidlinux-github
2019-10-11 20:20 ` voidlinux-github
2019-10-11 20:21 ` voidlinux-github
2019-10-11 20:39 ` voidlinux-github
2019-10-11 20:40 ` voidlinux-github
2019-10-12 7:44 ` voidlinux-github
2019-10-12 7:45 ` [ISSUE] [CLOSED] " voidlinux-github
2019-10-12 12:27 ` voidlinux-github
2019-10-14 6:36 ` voidlinux-github [this message]
2019-10-14 7:20 ` voidlinux-github
2019-10-14 8:32 ` voidlinux-github
2019-10-14 14:55 ` voidlinux-github
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191014063631.j8FNH3i8RJw_zBbgo834fyusCkYKBHoZkM8Yzb75D_I@z \
--to=voidlinux-github@inbox.vuxu.org \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).