Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uclibc support #1603

Merged
merged 1 commit into from
Jan 25, 2022
Merged

uclibc support #1603

merged 1 commit into from
Jan 25, 2022

Conversation

skrap
Copy link
Contributor

@skrap skrap commented Dec 7, 2021

uclibc is a libc alternative (peer to glibc and musl) which is used in low-resource embedded linux applications.

It's supported in rust as the target_env of several tier 3 targets, but nix currently doesn't build. This patch provides a few customizations to get uclibc building.

To test:

Thanks for your consideration!

@rtzoeller
Copy link
Collaborator

Thanks! Changes LGTM, although I didn't run the tests. A few thoughts....

  • Is armv7-unknown-linux-uclibceabihf the primary target you are intending to support with these changes? I tried building with some of the other uclibc targets and had mixed success: only armv7-unknown-linux-uclibceabihf and armv5te-unknown-linux-uclibceabi build successfully, while the mips, mipsel, and x86_64 targets fail to build.
    • If yes we might consider adding armv7-unknown-linux-uclibceabihf to the list of targets we build for, similar to how we support other tier 3 targets like x86_64-unknown-dragonfly using -Zbuild-std. It seems like the effort to support uclibc is likely low for any individual PR, but that the build could easily break if we aren't validating it.
  • We'll want to squash/rebase the commits before merging. This doesn't necessarily need to happen now, as I imagine we'll hold off on submitting this until after the 0.23.1 release, and more changes could be required.

@skrap
Copy link
Contributor Author

skrap commented Dec 8, 2021

Thanks!

Is armv7-unknown-linux-uclibceabihf the primary target you are intending to support with these changes?

Yes, and I am doing so with corporate backing for a long-term product need. I would be glad to have this build running in CI to catch any errors early. I'm happy to make those changes if you point me in the right direction.

We'll want to squash/rebase the commits before merging.

Yes, that is fine. I can do that once the main branch is ready for these changes. Want to let me know with a comment here? Or some other way?

Thanks again!

@rtzoeller rtzoeller added this to the 0.24.0 milestone Dec 10, 2021
Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought uclibc was used with RTOSes and microcontrollers, not Linux. Is it used with both?

@@ -776,7 +776,7 @@ libc_bitflags! {
ALTWERASE;
IEXTEN;
#[cfg(not(target_os = "redox"))]
EXTPROC;
EXTPROC as tcflag_t; // uclibc gets the type wrong
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this due to a bug in libc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it seems that libc's uclibc module doesn't have the right type for this item. We could accept this change here, pending a fix in libc, or I could try to get a libc change through first. Preferences?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's fix it in libc first.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking in here- I'm pushing through the changes in libc but it's a bit slowed by some larger sibling changes. I am still definitely pursuing this PR :)

@rtzoeller
Copy link
Collaborator

I thought uclibc was used with RTOSes and microcontrollers, not Linux. Is it used with both?

I believe it is used with embedded devices which run Linux. https://gogs.waldemar-brodkorb.de/oss/uclibc-ng

rust-lang/libc has it alongside glibc and musl: https://github.com/rust-lang/libc/tree/master/src/unix/linux_like/linux

bors added a commit to rust-lang/libc that referenced this pull request Dec 15, 2021
uclibc: fix type of EXTPROC.

All of the other related constants are of type `tcflag_t`, but this one was wrong.  This change will fix the build of `nix`.

(Ref nix-rust/nix#1603)
@lancethepants
Copy link

Also looking forward to uclibc support as I am trying to bring up armv7-unknown-linux-uclibceabi as new tier3 target.
rust-lang/rust#92383
Tested this patch and it enabled me to compile my application. Not sure if I tested before or after #1571, but hopefully @skrap will keep on it.

@rtzoeller
Copy link
Collaborator

rtzoeller commented Jan 18, 2022

@skrap with rust-lang/libc#2615 being submitted, I believe this can likely be rebased and squashed.

Here's an example of how to build tier 3 targets in nix's CI:

nix/.cirrus.yml

Lines 280 to 282 in 18d1f62

- name: OpenBSD x86_64
env:
TARGET: x86_64-unknown-openbsd

nix/bors.toml

Line 29 in 18d1f62

"OpenBSD x86_64",

@skrap
Copy link
Contributor Author

skrap commented Jan 19, 2022

Thanks! I'm working on this now. Unfortunately we'll need more changes to libc as well before this can succeed, but I'll be sure to reference this PR in any libc PRs so that those watching here can keep track of the progress if they like.

@skrap
Copy link
Contributor Author

skrap commented Jan 20, 2022

For now, I'm expecting CI to fail until:

  • libc cuts a new version to depend upon
  • I can track down the last few failures, which may be related to qemu user-space emulation inconsistencies

@skrap
Copy link
Contributor Author

skrap commented Jan 20, 2022

Ref https://gitlab.com/qemu-project/qemu/-/issues/829 which is causing failures in test_openat (and maybe more places) when testing under qemu user-space emulation.

@skrap skrap force-pushed the master branch 2 times, most recently from 134dd22 to 91e8eb3 Compare January 20, 2022 15:59
@skrap
Copy link
Contributor Author

skrap commented Jan 20, 2022

OK, this PR should be good at this point! (Tempting fate by saying this before CI has completed...)

@skrap
Copy link
Contributor Author

skrap commented Jan 20, 2022

The CI failures seem independent of these changes. Perhaps it's a new clippy lint?

@rtzoeller
Copy link
Collaborator

The CI failures seem independent of these changes. Perhaps it's a new clippy lint?

Was just responding about that. I'll investigate and fix it independently of this PR, and will try to look at this in the next day or two.

README.md Outdated Show resolved Hide resolved
src/sys/signal.rs Show resolved Hide resolved
src/sys/socket/addr.rs Outdated Show resolved Hide resolved
test/test_fcntl.rs Show resolved Hide resolved
test/sys/mod.rs Outdated Show resolved Hide resolved
test/test_fcntl.rs Show resolved Hide resolved
@skrap
Copy link
Contributor Author

skrap commented Jan 24, 2022

rebased on master to resolve conflicted Cargo.toml file.

@rtzoeller
Copy link
Collaborator

bors r+

@bors bors bot merged commit 5cd01a1 into nix-rust:master Jan 25, 2022
@skrap
Copy link
Contributor Author

skrap commented Jan 28, 2022

Thanks for the review and the merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants