problem building some programs on musl #1361

sever2806 · 2019-04-25T00:04:33Z

cabulertion.
i had problem while building uutils on musl
namely i am getting errors :

error[E0432]: unresolved import `libc::utmpx`
  --> src/uucore/utmpx.rs:44:5
   |
44 | use libc::utmpx;
   |     ^^^^^^^^^^^ no `utmpx` in the root

error[E0432]: unresolved import `libc::getutxent`
  --> src/uucore/utmpx.rs:48:9
   |
48 | pub use libc::getutxent;
   |         ^^^^^^---------
   |         |     |
   |         |     help: a similar name exists in the module: `getgrent`
   |         no `getutxent` in the root

error[E0432]: unresolved import `libc::setutxent`
  --> src/uucore/utmpx.rs:49:9
   |
49 | pub use libc::setutxent;
   |         ^^^^^^---------
   |         |     |
   |         |     help: a similar name exists in the module: `setgrent`
   |         no `setutxent` in the root

error[E0432]: unresolved import `libc::endutxent`
  --> src/uucore/utmpx.rs:50:9
   |
50 | pub use libc::endutxent;
   |         ^^^^^^---------
   |         |     |
   |         |     help: a similar name exists in the module: `endmntent`
   |         no `endutxent` in the root

error[E0432]: unresolved import `libc::utmpxname`
  --> src/uucore/utmpx.rs:52:9
   |
52 | pub use libc::utmpxname;
   |         ^^^^^^---------
   |         |     |
   |         |     help: a similar name exists in the module: `tmpnam`
   |         no `utmpxname` in the root

error[E0432]: unresolved import `libc::__UT_LINESIZE`
  --> src/uucore/utmpx.rs:69:13
   |
69 |     pub use libc::__UT_LINESIZE as UT_LINESIZE;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `__UT_LINESIZE` in the root

error[E0432]: unresolved import `libc::__UT_NAMESIZE`

The text was updated successfully, but these errors were encountered:

Arcterus · 2019-04-28T03:57:07Z

This might just be due to an out-of-date libc or something. I'll take a look.

Ecordonnier · 2023-04-06T19:15:04Z

I reported the issue to the libc crate: rust-lang/libc#3190
This can still be reproduced with version 0.0.18, so I think this ticket should be reopened:

$ rustup target add x86_64-unknown-linux-musl
$ cargo build -p uu_users --target=x86_64-unknown-linux-musl
...
13 | use uucore::utmpx::{self, time, Utmpx};
   |             ^^^^^   ^^^^ no utmpx in the root
   |             |
   |             could not find utmpx in uucore``

tertsdiepraam · 2023-04-06T21:28:29Z

Looks like a slightly different issue right? Could you make a new one? On our side, we should probably disable that functionality for the time being.

Ecordonnier · 2023-04-06T22:01:46Z

As far as I understand, the issue is almost the same. This ticket was worked-around with this commit , so now instead of uucore failing and producing the logs in this ticket, the utilities which depend on uucore's utmpx functionality are failing when building for musl. The proper long-term fix is to implement the functionality on libc's side, which I'll try to work on.

rivy · 2023-04-09T13:14:42Z

I'd probably call this more of a platform support documentation issue than a coding bug.

I can add some compiler_error!() code based on platform or a proc_macro testing for module functionality that returns a more obvious error message for the utilities that are platform-limited. Maybe something like "Unsupported; platform ('...') is missing required 'utmpx' support" as a compiler error.

rivy · 2023-04-09T15:20:49Z

[...] The proper long-term fix is to implement the functionality on libc's side, which I'll try to work on.

That's a big hill to climb; I wish you luck!

Ecordonnier · 2023-05-01T21:42:45Z

I investigated this further, and while the utmpx functions are exported by musl in a header-file, those are only stub implementations doing nothing. I'll try to improve the build errors, but compiling e.g. the utility "users" using musl stubs doesn't really make sense, because while it would compile, it would produce a runtime error (this explains why only stubs are provided).

tertsdiepraam · 2023-08-19T10:36:58Z

@Ecordonnier Just checking in here. I see that rust-lang/libc#3190 and rust-lang/libc#3213 are still open. Should we poll there to see if we can get them merged?

Ecordonnier · 2023-08-19T13:28:32Z

@tertsdiepraam I'm not very familiar with the rust libc project, but my understanding is that this PR is changing the API and therefore tagged as "breakage-candidate" so that it can be merged when they do a release with non-backwards-compatible API. I asked them for confirmation in the PR.

tertsdiepraam · 2023-08-19T13:41:12Z

Interesting! I'll subscribe to the PR. Thanks!

Ecordonnier · 2024-01-11T14:17:41Z

The required functions were added to libc ( rust-lang/libc@e3caaf6 ), however those changes will be available via cargo only once libc 0.3 is released ( rust-lang/libc#3248 ). The main branch of libc is now used for the development of 0.3, and the version 0.2 is developed on the branch libc-0.2 (and hence the libc release 0.2.152 does NOT contain e3caaf6b0ea08a ).
The release of libc 0.3 is tracked at rust-lang/libc#3248 (it will probably take a while).

Edit May 2024: The status is still the same. libc version 1.0 will be needed in order to fix this, and this will probably take at least several months: rust-lang/libc#3248

Ecordonnier · 2025-03-11T14:58:43Z

According to https://github.com/rust-lang/libc/releases/tag/0.2.165 , the utmpx API should now be available for musl (even though keep in mind those are stub functions which don't do anything because musl chose to not implement those for security reasons, but it should at least compile). See this commit which was merged into 0.2.165.

libc 0.2.170 is currently used in Cargo.lock so those changes are available to coreutils.

I tried removing this line, however it is not enough and it still doesn't build:

coreutils$ cargo build -p uu_users --target=x86_64-unknown-linux-musl
   Compiling uucore v0.0.30 (/home/ecordonnier/dev/coreutils/src/uucore)
error[E0432]: unresolved import `libc::utmpxname`
  --> src/uucore/src/lib/features/utmpx.rs:48:9
   |
48 | pub use libc::utmpxname;
   |         ^^^^^^---------
   |         |     |
   |         |     help: a similar name exists in the module: `tmpnam`
   |         no `utmpxname` in the root

I opened rust-lang/libc#4322 as follow-up issue.

Unfortunately, the name of those constants are not standardized: glibc uses __UT_HOSTSIZE, __UT_LINESIZE, __UT_NAMESIZE musl uses UT_HOSTSIZE, UT_LINESIZE, UT_NAMESIZE See: 1. https://git.musl-libc.org/cgit/musl/tree/include/utmpx.h 2. https://github.com/bminor/glibc/blob/master/sysdeps/gnu/bits/utmpx.h#L35 This is a partial fix for uutils#1361 Signed-off-by: Etienne Cordonnier <[email protected]>

Ecordonnier · 2025-03-15T23:14:31Z

I think I have managed to make it work in this test branch: https://github.com/Ecordonnier/coreutils/tree/eco/enable-musl
I'll try to get it merged to coreutils's main branch. This requires:

my PR to be merged to libc AND backported to the 0.2 branch
libc to get bumped in coreutils's Cargo.toml to a release containing the fixes
commits from my test branch to be merged

sylvestre · 2025-03-16T09:02:36Z

excellent, thanks!
don't hesitate to add CI to make sure we don't regress!

Unfortunately, the name of those constants are not standardized: glibc uses __UT_HOSTSIZE, __UT_LINESIZE, __UT_NAMESIZE musl uses UT_HOSTSIZE, UT_LINESIZE, UT_NAMESIZE See: 1. https://git.musl-libc.org/cgit/musl/tree/include/utmpx.h 2. https://github.com/bminor/glibc/blob/master/sysdeps/gnu/bits/utmpx.h#L35 This is a partial fix for uutils#1361 Signed-off-by: Etienne Cordonnier <[email protected]>

Ecordonnier · 2025-04-12T16:53:15Z

My libc PR got merged and backported to the 0.2 branch, so I've sent a PR to re-enable utmpx for musl in uutils-coreutils. However this will be mergeable only after libc version 0.2.172 is released (I think it will take maximum 1-2 months, looking at their release frequency). I have tested how those stub functions are handled in GNU coreutils. As you can see in my tests GNU coreutils has no special handling for musl, and returns a success exit value even though the commands don't find the users on the system. I think uutils coreutils should do the same thing and ship those utilities as-is when compiling with musl, in order to be a drop-in replacement for GNU coreutils also when it is compiled with musl:

the coreutils utillities using utmpx are "pinky", "uptime", "users", "who"


with musl:

root@qemuarm64:~# users --version
users (GNU coreutils) 9.6
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Joseph Arceneaux and David MacKenzie.

root@qemuarm64:~# users
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# pinky
Login    Name                 TTY      Idle   When         Where
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# uptime
 12:58:47 up 0 min,  0 users,  load average: 0.07, 0.02, 0.00
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# ls /usr/lib/libc*
libc.so       
root@qemuarm64:~# who
root@qemuarm64:~# echo $?
0





with glibc:
root@qemuarm64:~# ls -l /lib/libc*
libc.so.6   
root@qemuarm64:~# users --version
users (GNU coreutils) 9.6
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Joseph Arceneaux and David MacKenzie.
root@qemuarm64:~# users
root
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# pinky
Login    Name                 TTY      Idle   When         Where
root     root                *ttyAMA0         Apr 12 13:42
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# uptime
 13:42:55 up 0 min,  1 user,  load average: 0.08, 0.02, 0.01
root@qemuarm64:~# echo $?
0
root@qemuarm64:~# who
root     ttyAMA0      Apr 12 13:42
root@qemuarm64:~# echo $?
0

musl provides stubs of those functions, so let's enable the feature so that it can compile with musl. Note that those stubs always return a success exit value, and commands such as "users" will report an empty list of users, when calling those stubs. This is consistent with the behavior of GNU coreutils which does the same thing. The coreutils utillities using utmpx are "pinky", "uptime", "users", "who". This is the expected behavior when using those utilities compiled with those musl utmpx stubs: ``` root@qemuarm64:~# users root@qemuarm64:~# echo $? 0 root@qemuarm64:~# pinky Login Name TTY Idle When Where root@qemuarm64:~# echo $? 0 root@qemuarm64:~# uptime 12:58:47 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 root@qemuarm64:~# echo $? 0 root@qemuarm64:~# who root@qemuarm64:~# echo $? 0 ``` Closes uutils#1361 Signed-off-by: Etienne Cordonnier <[email protected]>

musl provides stubs of those functions, and those stubs are available in the libc crate version 0.2.172. Thus let's enable the feature so that it can compile with musl. Note that those stubs always return a success exit value, and commands such as "users" will report an empty list of users, when calling those stubs. This is consistent with the behavior of GNU coreutils which does the same thing. The coreutils utillities using utmpx are "pinky", "uptime", "users", "who". This is the expected behavior when using those utilities compiled with those musl utmpx stubs: ``` root@qemuarm64:~# users root@qemuarm64:~# echo $? 0 root@qemuarm64:~# pinky Login Name TTY Idle When Where root@qemuarm64:~# echo $? 0 root@qemuarm64:~# uptime 12:58:47 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 root@qemuarm64:~# echo $? 0 root@qemuarm64:~# who root@qemuarm64:~# echo $? 0 ``` Closes uutils#1361 Signed-off-by: Etienne Cordonnier <[email protected]>

bump libc to 0.2.172 musl provides stubs of utmpx functions, and those stubs are available in the libc crate version 0.2.172. Thus let's enable the feature so that it can compile with musl. Note that those stubs always return a success exit value, and commands such as "users" will report an empty list of users, when calling those stubs. This is consistent with the behavior of GNU coreutils which does the same thing. The coreutils utillities using utmpx are "pinky", "uptime", "users", "who". This is the expected behavior when using those utilities compiled with those musl utmpx stubs: ``` root@qemuarm64:~# users root@qemuarm64:~# echo $? 0 root@qemuarm64:~# pinky Login Name TTY Idle When Where root@qemuarm64:~# echo $? 0 root@qemuarm64:~# uptime 12:58:47 up 0 min, 0 users, load average: 0.07, 0.02, 0.00 root@qemuarm64:~# echo $? 0 root@qemuarm64:~# who root@qemuarm64:~# echo $? 0 ``` Closes uutils#1361 Signed-off-by: Etienne Cordonnier <[email protected]>

Arcterus added B - medium priority P - Linux U - All (uucore) labels Apr 28, 2019

rivy mentioned this issue Feb 10, 2020

Add GHA CICD #1449

Merged

rivy closed this as completed in #1449 Apr 13, 2020

Ecordonnier mentioned this issue Apr 4, 2023

uutils coreutils 0.0.18 openembedded/meta-openembedded#670

Closed

tertsdiepraam reopened this Apr 7, 2023

rivy self-assigned this Apr 9, 2023

Ecordonnier mentioned this issue Mar 15, 2025

utmpx.rs: use correct constant names for musl libc #7459

Merged

Ecordonnier mentioned this issue Mar 22, 2025

Add missing utmpx apis for linux musl rust-lang/libc#4332

Merged

3 tasks

Ecordonnier mentioned this issue Apr 12, 2025

enable utmpx feature for musl #7740

Merged

tertsdiepraam closed this as completed in #7740 Apr 17, 2025

tertsdiepraam closed this as completed in f0440ae Apr 17, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

problem building some programs on musl #1361

problem building some programs on musl #1361

sever2806 commented Apr 25, 2019 •

edited by tertsdiepraam

Loading

Arcterus commented Apr 28, 2019

Ecordonnier commented Apr 6, 2023 •

edited

Loading

tertsdiepraam commented Apr 6, 2023

Ecordonnier commented Apr 6, 2023

rivy commented Apr 9, 2023

rivy commented Apr 9, 2023 •

edited

Loading

Ecordonnier commented May 1, 2023

tertsdiepraam commented Aug 19, 2023

Ecordonnier commented Aug 19, 2023

tertsdiepraam commented Aug 19, 2023

Ecordonnier commented Jan 11, 2024 •

edited

Loading

Ecordonnier commented Mar 11, 2025 •

edited

Loading

Ecordonnier commented Mar 15, 2025

sylvestre commented Mar 16, 2025

Ecordonnier commented Apr 12, 2025 •

edited

Loading

problem building some programs on musl #1361

problem building some programs on musl #1361

Comments

sever2806 commented Apr 25, 2019 • edited by tertsdiepraam Loading

Arcterus commented Apr 28, 2019

Ecordonnier commented Apr 6, 2023 • edited Loading

tertsdiepraam commented Apr 6, 2023

Ecordonnier commented Apr 6, 2023

rivy commented Apr 9, 2023

rivy commented Apr 9, 2023 • edited Loading

Ecordonnier commented May 1, 2023

tertsdiepraam commented Aug 19, 2023

Ecordonnier commented Aug 19, 2023

tertsdiepraam commented Aug 19, 2023

Ecordonnier commented Jan 11, 2024 • edited Loading

Ecordonnier commented Mar 11, 2025 • edited Loading

Ecordonnier commented Mar 15, 2025

sylvestre commented Mar 16, 2025

Ecordonnier commented Apr 12, 2025 • edited Loading

sever2806 commented Apr 25, 2019 •

edited by tertsdiepraam

Loading

Ecordonnier commented Apr 6, 2023 •

edited

Loading

rivy commented Apr 9, 2023 •

edited

Loading

Ecordonnier commented Jan 11, 2024 •

edited

Loading

Ecordonnier commented Mar 11, 2025 •

edited

Loading

Ecordonnier commented Apr 12, 2025 •

edited

Loading