Skip to content
Snippets Groups Projects
Select Git revision
  • dev
  • main default protected
  • base
  • master
4 results
Search by author
  • Any Author
0 authors
  1. Jul 17, 2018
  3. Jul 16, 2018
  5. Jul 14, 2018
  7. Jul 12, 2018
  9. Jul 10, 2018
  11. Jul 09, 2018
  13. Jul 08, 2018
  15. Jul 06, 2018
  17. Jul 05, 2018
  19. Jul 04, 2018
  21. Jul 03, 2018
  23. Jul 01, 2018
  25. Jun 30, 2018
    • bors's avatar
      Auto merge of #1026 - papertigers:master, r=alexcrichton · a9666f60
      bors authored 
      illumos header translation is wrong 02000000 should be 0x80000

I am recently getting into rust and discovered that tokio wasn't working on illumos.  I traced it back to mio but ultimately the issue ended up being this value in the libc crate.  It looks like the octal value isn't properly translated to the rust crate as hex.  Here's a test program I was using on linux and illumos:

```rust
extern crate libc;

#[allow(dead_code)]
const ILLUMOS_EPOLL_CLOEXEC: i32 = 0x80000;

fn find_func() -> usize {
    unsafe { libc::dlsym(libc::RTLD_DEFAULT, "epoll_create1\0".as_ptr() as *const _) as usize }
}

fn main() {
    let addr = find_func();

    #[allow(unused_variables)]
    let hex = format!("{:x}", addr);

    // I think the position changes per run on linux due to something like ASLR
    // so we only test on solaris for this use case
    #[cfg(target_os = "solaris")]
    assert_eq!(hex, "ffffbf7fff226fe0"); // confirmed with addrtosymstr

    unsafe {
        let f = std::mem::transmute::<usize, fn(i32) -> i32>(addr);

        #[cfg(target_os = "linux")]
        let epfd = f(libc::EPOLL_CLOEXEC);

        #[cfg(target_os = "solaris")]
        let epfd = f(ILLUMOS_EPOLL_CLOEXEC);

        println!("call to epoll_create1 returned: {}", epfd);
    }
}
```

Which outputs the following:

```
# cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/dlsym`
call to epoll_create1 returned: 3
```

Edit: typo
      a9666f60
    • Mike Zeller's avatar
      illumos header translation is wrong 02000000 should be 0x80000 · 2341e6f3
      Mike Zeller authored
      2341e6f3
  27. Jun 28, 2018
    • bors's avatar
      Auto merge of #1019 - est31:master, r=alexcrichton · 7cac8d0c
      bors authored 
      Simplify the stdbuild section

Found this when encountering the code in the rustc submodule and changing the allow for the warnings to deny.

* `no_std` is stable so it does not have to be listed in the `feature` attribute
* `no_std` as an attribute for the crate is already implied by the `#![cfg_attr(not(feature = "use_std"), no_std)]` below
* `staged_api` as an attribute gives a warning. That also matches my knowledge.
      7cac8d0c
    • bors's avatar
      Auto merge of #1024 - nielx:master, r=alexcrichton · 0d0a5f75
      bors authored 
      Haiku: Add more IP_* and IPV6_* constants.

These are used in the socket2 library.
      0d0a5f75
    • bors's avatar
      Auto merge of #1022 - sfackler:phys-pages, r=alexcrichton · ac1a1193
      bors authored 
      Add _SC_PHYS_PAGES on macOS
      ac1a1193
    • bors's avatar
      Auto merge of #1023 - mksully22:ppc64le_libc, r=alexcrichton · 42a5ad8c
      bors authored 
      libc: changes to ppc64le musl branch to support building of rust on A…

…lpine

This PR includes changes to the libc musl branch to include the correct defines & declarations to support powerpc64.  Values that needed changes to a definition for powerpc64.rs that existed higher in the branch also resulted in a change that moved the definition down to the b32/mod.rs, b64/x86_64.rs to ensure that builds continued to work on those architectures.

Verification was done building rust for both ppc64le and x86_64 on Alpine as described in the git project
https://github.com/mksully22/ppc64le_alpine_rust_1.26.2
      42a5ad8c