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 09:20:20 +0200 [thread overview]
Message-ID: <20191014072020.wOqmCvS-THGd6xbNbs7aRLLzzEPY85R4ewIlpcHXvDs@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: 1310 bytes --]
New comment by Hoshpak on void-packages repository
https://github.com/void-linux/void-packages/issues/14721#issuecomment-541529072
Comment:
I was refering to https://pubs.opengroup.org/onlinepubs/9699919799/ which states:
```
The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided.
void endutxent(void);
struct utmpx *getutxent(void);
struct utmpx *getutxid(const struct utmpx *);
struct utmpx *getutxline(const struct utmpx *);
struct utmpx *pututxline(const struct utmpx *);
void setutxent(void);
```
Musl implements that by declaring the functions and just having them return NULL when called in https://git.musl-libc.org/cgit/musl/tree/src/legacy/utmpx.c .
This is arguably a bad way to do it but I think since the standard does not mandate an implementation they are not technically breaking the specification. So the check for the function's existance will succeed, the code will compile but it will not work the way it's inteded to do.
We had the same issue with glibc earlier since runit as an init system does not write utmp records as other init systems do so libvirt would fail the same way as it did on musl. We worked around that however by writing a boot record within our own boot scripts.
next prev parent reply other threads:[~2019-10-14 7:20 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
2019-10-14 7:20 ` voidlinux-github [this message]
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=20191014072020.wOqmCvS-THGd6xbNbs7aRLLzzEPY85R4ewIlpcHXvDs@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).