Fix ioctl constants for musl target envs. #289
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
According to musl's source, the `ioctl` [function
signature][musl-ioctl-h] takes an `int` as the request argument (i.e. an
`i32`) which is reflected in this crate's [ioctl
binding][musl-ioctl-rs]. It looks like when the ioctl constants were
added that [glibc's default][glibc-ioctl-h] of a `c_ulong` type was used
for the musl values as well, rather than a `c_int` type. This change
updates these constants to a `c_int` so that they match the expected
function call type.
Here is a minimal reproduction of the issue. Given this Rust program:
```rust
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
When run against the `x86_64-unknwon-linux-gnu` and
`x86_64-unknown-linux-musl` targets, we see the difference in behavior:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
src/main.rs:13:30: 13:40 error: mismatched types:
expected `i32`,
found `u64` [E0308]
src/main.rs:13 ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
^~~~~~~~~~
src/main.rs:13:30: 13:40 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `libc-musl-ioctl`.
To learn more, run the command again with --verbose.
```
Working against this fix:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Updating git repository `https://github.com/fnichol/rust-lang-libc.git`
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-musl/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
```
[musl-ioctl-rs]:
https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/fn.ioctl.html
[musl-ioctl-h]:
https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h
[glibc-ioctl-h]:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/include/sys/ioctl.h
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
fnichol
added a commit
to habitat-sh/habitat
that referenced
this pull request
May 16, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
fnichol
added a commit
to habitat-sh/habitat
that referenced
this pull request
May 16, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
fnichol
added a commit
to habitat-sh/habitat
that referenced
this pull request
May 17, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
|
⌛ Testing commit 78d9be2 with merge a252236... |
bors
added a commit
that referenced
this pull request
May 17, 2016
Fix ioctl constants for musl target envs.
Heya!
I ran across this issue today while trying to build a portable static binary using the `x86_64-unknown-linux-musl` target. Took a bit of digging to make sure I understood what was going on, and while I may still be off the mark, I believe this is a fix to my issue.
Thanks!!
----
According to musl's source, the `ioctl` [function signature][musl-ioctl-h] takes an `int` as the request argument (i.e. an `i32`) which is reflected in this crate's [ioctl binding][musl-ioctl-rs]. It looks like when the ioctl constants were added that [glibc's default][glibc-ioctl-h] of a `c_ulong` type was used for the musl values as well, rather than a `c_int` type. This change updates these constants to a `c_int` so that they match the expected function call type.
Here is a minimal reproduction of the issue. Given this Rust program:
```rust
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
When run against the `x86_64-unknwon-linux-gnu` and
`x86_64-unknown-linux-musl` targets, we see the difference in behavior:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
src/main.rs:13:30: 13:40 error: mismatched types:
expected `i32`,
found `u64` [E0308]
src/main.rs:13 ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
^~~~~~~~~~
src/main.rs:13:30: 13:40 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `libc-musl-ioctl`.
To learn more, run the command again with --verbose.
```
Working against this fix:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Updating git repository `https://github.com/fnichol/rust-lang-libc.git`
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-musl/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
```
[musl-ioctl-rs]:
https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/fn.ioctl.html
[musl-ioctl-h]:
https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h
[glibc-ioctl-h]:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/include/sys/ioctl.h
thesentinels
pushed a commit
to habitat-sh/habitat
that referenced
this pull request
May 17, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
|
💥 Test timed out |
|
@bors: retry |
bors
added a commit
that referenced
this pull request
May 17, 2016
Fix ioctl constants for musl target envs.
Heya!
I ran across this issue today while trying to build a portable static binary using the `x86_64-unknown-linux-musl` target. Took a bit of digging to make sure I understood what was going on, and while I may still be off the mark, I believe this is a fix to my issue.
Thanks!!
----
According to musl's source, the `ioctl` [function signature][musl-ioctl-h] takes an `int` as the request argument (i.e. an `i32`) which is reflected in this crate's [ioctl binding][musl-ioctl-rs]. It looks like when the ioctl constants were added that [glibc's default][glibc-ioctl-h] of a `c_ulong` type was used for the musl values as well, rather than a `c_int` type. This change updates these constants to a `c_int` so that they match the expected function call type.
Here is a minimal reproduction of the issue. Given this Rust program:
```rust
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
When run against the `x86_64-unknwon-linux-gnu` and
`x86_64-unknown-linux-musl` targets, we see the difference in behavior:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
src/main.rs:13:30: 13:40 error: mismatched types:
expected `i32`,
found `u64` [E0308]
src/main.rs:13 ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
^~~~~~~~~~
src/main.rs:13:30: 13:40 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `libc-musl-ioctl`.
To learn more, run the command again with --verbose.
```
Working against this fix:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Updating git repository `https://github.com/fnichol/rust-lang-libc.git`
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-musl/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
```
[musl-ioctl-rs]:
https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/fn.ioctl.html
[musl-ioctl-h]:
https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h
[glibc-ioctl-h]:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/include/sys/ioctl.h
|
💥 Test timed out |
|
@alexcrichton Thanks for the quick turnaround! Is there anything I can do to help the bot, or is it just caught in timeout loop? |
|
@bors: retry Nah unfortunately the appveyor build is sometimes really slow ... |
bors
added a commit
that referenced
this pull request
May 18, 2016
Fix ioctl constants for musl target envs.
Heya!
I ran across this issue today while trying to build a portable static binary using the `x86_64-unknown-linux-musl` target. Took a bit of digging to make sure I understood what was going on, and while I may still be off the mark, I believe this is a fix to my issue.
Thanks!!
----
According to musl's source, the `ioctl` [function signature][musl-ioctl-h] takes an `int` as the request argument (i.e. an `i32`) which is reflected in this crate's [ioctl binding][musl-ioctl-rs]. It looks like when the ioctl constants were added that [glibc's default][glibc-ioctl-h] of a `c_ulong` type was used for the musl values as well, rather than a `c_int` type. This change updates these constants to a `c_int` so that they match the expected function call type.
Here is a minimal reproduction of the issue. Given this Rust program:
```rust
extern crate libc;
use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
fn main() {
let mut wsize = winsize {
ws_row: 0,
ws_col: 0,
ws_xpixel: 0,
ws_ypixel: 0,
};
unsafe {
ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
}
println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
wsize.ws_row,
wsize.ws_col,
wsize.ws_xpixel,
wsize.ws_ypixel);
}
```
When run against the `x86_64-unknwon-linux-gnu` and
`x86_64-unknown-linux-musl` targets, we see the difference in behavior:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
src/main.rs:13:30: 13:40 error: mismatched types:
expected `i32`,
found `u64` [E0308]
src/main.rs:13 ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
^~~~~~~~~~
src/main.rs:13:30: 13:40 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `libc-musl-ioctl`.
To learn more, run the command again with --verbose.
```
Working against this fix:
```
> cargo clean
> cargo run --target=x86_64-unknown-linux-gnu
Updating git repository `https://github.com/fnichol/rust-lang-libc.git`
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
> cargo clean
> cargo run --target=x86_64-unknown-linux-musl
Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
Running `target/x86_64-unknown-linux-musl/debug/libc-musl-ioctl`
Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
```
[musl-ioctl-rs]:
https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/fn.ioctl.html
[musl-ioctl-h]:
https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h
[glibc-ioctl-h]:
http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/include/sys/ioctl.h
|
☀️ Test successful - status-appveyor, travis |
|
Great!
|
bors
added a commit
that referenced
this pull request
May 31, 2016
Fix ioctl types for non-x86 musl This fixes up #289 by changing the type for other platforms as well.
jtimberman
pushed a commit
to habitat-sh/habitat
that referenced
this pull request
Jun 12, 2016
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
Susurrus
pushed a commit
to Susurrus/libc
that referenced
this pull request
Mar 26, 2017
Fix Travis-CI links.
raskchanky
pushed a commit
to habitat-sh/builder
that referenced
this pull request
Jan 18, 2018
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
raskchanky
pushed a commit
to habitat-sh/core
that referenced
this pull request
Jan 23, 2018
hab CLI
-------
This change is part spike and experiment and part functional. It is a
first attempt at unifying the `hab` CLI output and formatting to be more
consisten and easier to scan as a newcomer (in the short term) and
experienced user (in the long term).
Most of the commands have the following narrative, much like an essay:
* An intro/goal/summary of the objective
* A middle with the concrete steps to achieve the objective
* A final summary/conclusion to confirm success
Here is an example of a package install invocation:
```
> hab install core/redis
» Installing core/redis
↓ Downloading core/glibc/2.22/20160427193532
16.21 MB / 16.21 MB \ [========================================] 100.00 % 2.98 MB/s
✓ Installed core/glibc/2.22/20160427193532
↓ Downloading core/linux-headers/4.3/20160427193435
798.63 KB / 798.63 KB | [======================================] 100.00 % 1.56 MB/s
✓ Installed core/linux-headers/4.3/20160427193435
↓ Downloading core/redis/3.0.7/20160427222845
1.46 MB / 1.46 MB | [==========================================] 100.00 % 3.28 MB/s
✓ Installed core/redis/3.0.7/20160427222845
★ Install of core/redis complete with 3 packages installed.
```
musl/libc/ioctl
---------------
In the course of building in a progress bar, an issue was found with in the
`libc` crate relating to the types of ioctl contants when used by musl (more
detail in: rust-lang/libc#289). Unfortunately, this
meant vendoring libc so that it would be used as a transitive dependency in the
crates that generated the errors (currently this is the `pbr` crate, which is
completely correct in tits implementation). Without this temporary measure, the
`hab` CLI won't build as-is with the musl target. The other option is to
feature-disable the progress bar until the upstream is resolved, but it really
hampers the far superior user experience that a progress bar like this
provides.
Signed-off-by: Fletcher Nichol <fnichol@nichol.ca>
Pull request: #522
Approved by: fnichol
danielverkamp
pushed a commit
to danielverkamp/libc
that referenced
this pull request
Apr 28, 2020
This commit provides insurance that intrinsics are only introduced with known canonical types (`__m128i` and such) instead of also allowing `u8x16` for example.
workingjubilee
added a commit
to workingjubilee/libc
that referenced
this pull request
Feb 23, 2021
This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR rust-lang#289, PR rust-lang#301, or PR rust-lang#1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints.
workingjubilee
added a commit
to workingjubilee/libc
that referenced
this pull request
Feb 23, 2021
This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR rust-lang#289, PR rust-lang#301, or PR rust-lang#1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX.
bors
added a commit
that referenced
this pull request
Feb 23, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 23, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 24, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 24, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 24, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 24, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 24, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 25, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 25, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 25, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 25, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
bors
added a commit
that referenced
this pull request
Feb 26, 2021
Fix mips64-musl ioctl consts to c_int This arch was overlooked or unspecified in earlier PRs that fixed c_ulong to c_int for ioctl.h consts for musl, see PR #289, PR #301, or PR #1097 for such prior art, however these are still args to fn ioctl on mips64-musl, which is expecting c_ints. Some numbers acquired casts to reflect the fact the data is being used and (so should be written as) an unsized bitfield, even if the value is greater than i32::MAX. Currently rustc is not building on mips64-linux-musl because of this error.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Heya!
I ran across this issue today while trying to build a portable static binary using the
x86_64-unknown-linux-musltarget. Took a bit of digging to make sure I understood what was going on, and while I may still be off the mark, I believe this is a fix to my issue.Thanks!!
According to musl's source, the
ioctlfunction signature takes anintas the request argument (i.e. ani32) which is reflected in this crate's ioctl binding. It looks like when the ioctl constants were added that glibc's default of ac_ulongtype was used for the musl values as well, rather than ac_inttype. This change updates these constants to ac_intso that they match the expected function call type.Here is a minimal reproduction of the issue. Given this Rust program:
When run against the
x86_64-unknwon-linux-gnuandx86_64-unknown-linux-musltargets, we see the difference in behavior:Working against this fix: