Fixes https://github.com/uutils/coreutils/issues/6591
"feat_external_stdbuf": use an external libstdbuf.so for stdbuf instead of embedding it into
the stdbuf binary.
There are 2 use-cases:
1. Installation of uutils-coreutils using cargo install (e.g. from crates.io
which supports only "cargo install" as installation method). In this case,
installing libstdbuf.so is impossible, because "cargo install" installs
only binary programs (no cdylib), thus libstdbuf.so must be embedded into
stdbuf and written to /tmp at runtime. This is a hack, and may not work
on some platforms, e.g. because the SELinux permissions may not allow
stdbuf to write to /tmp, /tmp may be read-only, libstdbuf.so may not work
at all without SELinux labels, etc.
2. Installation of uutils-coreutils using an external tool, e.g. dpkg/apt on
debian. In this case, libstdbuf.so should be installed separately to its
correct location and the environment variable LIBSTDBUF_PATH configures the
installation path during the build. E.g. LIBSTDBUF_PATH="/lib/libstdbuf.so"
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
* chore: cleanup workspace crates
* properly add all crates to the workspace cargo.toml as members
* except `fuzz` because it still has some issues, TBD
* use quotes around `true` and `false` to ensure there is no bool confusion
* remove a few leftover readme comments
* mark all unpublishable crates as `publish = false` to avoid accidental publishing
* Add `uutests` to the main workspace
* grammar
* a bit more cleanup based on feedback
* revert true/false
* Update tests/benches/factor dependencies
* cp: migrate from quick-error to thiserror
fixes: #7916
* Remove quick-error
Now that we have migrated to thiserror, we can remove quick-error
* cp: fix test failures
* cp: fix fmt error
Summary:
Partial fix for https://github.com/uutils/coreutils/issues/6591
The current code declare libstdbuf as a build-dependency of stdbuf as a
workaround to enforce that libstdbuf is compiled before stdbuf. This breaks
cross-compilation, because build-dependencies were compiled for the host
architecture, and not for the target architecture.
The reason this workaround is necessary is that bindeps is available only in nightly at the moment:
https://rust-lang.github.io/rfcs/3028-cargo-binary-dependencies.html
This commit replaces the "build-dependency" workaround with another workaround:
calling cargo manually to build libstdbuf in the build.rs of stdbuf, in order to ensure that libstdbuf is built before stdbuf.
Changes:
- Removed cpp/cpp_build dependencies:
The cpp, cpp_build, and related dependencies were removed because they made cross-compilation in a build.rs file very complex, since you need
to pass proper CXX env variables for cross-compilation, whereas cross-compiling rust code using cargo is quite simple.
Provided Rust implementations for getting stdin, stdout, and stderr pointers.
Switched from C++/cpp macro-based initialization to using the Rust ctor crate for library initialization.
- Remove "feat_require_crate_cpp" which is not needed any more, since stdbuf was the only utility using the cpp crate.
Tests:
This commit fixes e.g. this test:
cross test --target aarch64-unknown-linux-gnu --features stdbuf test_stdbuf::test_libstdbuf_preload -- --nocapture
- The "i686" build of stdbuf was also broken (stdbuf 32 bits, but libstdbuf 64 bits) and test_stdbuf::test_libstdbuf_preload of the i686 builds in github CI serves as regression
test for this issue, no need to add a cross-rs test for aarch64.
- The x86_64 musl build of stdbuf was also broken and was passing tests in CI only because it was compiled with the wrong libc (glibc instead of musl)
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
* update chrono crate version and switch to new_lenient use
* bring back custom_tz_fmt and update test
* update chrono version in fuzz lock file
* replace boxing with parse_to_owned
After the addition of utmpx, feat_os_unix_musl is now identical to feat_os_unix and is thus not needed any more.
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
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#1361
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Running this command showed a list of all lints across all crates:
```shell
cargo clippy --all-targets --workspace --message-format=json --quiet | jq -r '.message.code.code | select(. != null and startswith("clippy::"))' | sort | uniq -c | sort -h -r
```
This resulted in a list that I added to the `[workspace.lints.clippy]` in the root Cargo.toml. Afterwards, I commented out a few simpler lints. Subsequentely, I will go through this list, trying to address items in smaller batches.
I am not sure what the original issue was, but it seems to work:
```
cargo build --target=x86_64-unknown-linux-musl --features feat_os_unix_musl
...
coreutils$ ./target/x86_64-unknown-linux-musl/debug/coreutils stdbuf -o L echo "foobar"
foobar
```
