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 16, 2018
  3. Jul 12, 2018
  5. Jul 10, 2018
  7. Jul 09, 2018
  9. Jul 08, 2018
  11. Jul 06, 2018
  13. Jul 05, 2018
  15. Jul 04, 2018
  17. Jul 03, 2018
  19. Jul 01, 2018
  21. 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
  23. 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
    • bors's avatar
      Auto merge of #1021 - redox-os:master, r=alexcrichton · f36341e2
      bors authored 
      Add getpid on Redox

None
      f36341e2
    • bors's avatar
      Auto merge of #1018 - scottlamb:pr-fdopendir, r=alexcrichton · 93bc59e6
      bors authored 
      add fdopendir on macOS

Fixes #1017

I moved it up to src/unix/mod.rs, as it's specified in POSIX.1-2008 and
appears to be implemented on every Unix-like system.

The symbol names on macOS appear similar to those for opendir; I found
them via the commands below. I tested the x86_64 version;
fdopendir$INODE64 worked as expected.

$ nm -arch x86_64 /usr/lib/system/libsystem_c.dylib | grep fdopendir
000000000007ea6d T _fdopendir
000000000002ba97 T _fdopendir$INODE64
$ nm -arch i386 /usr/lib/system/libsystem_c.dylib | grep fdopendir
00082d1e T _fdopendir
0002b528 T _fdopendir$INODE64$UNIX2003
00082d1e T _fdopendir$UNIX2003
      93bc59e6
  25. Jun 27, 2018
  27. Jun 20, 2018
  29. Jun 18, 2018
  31. Jun 15, 2018
  33. Jun 09, 2018
  35. Jun 08, 2018
    • est31's avatar
      Simplify the stdbuild section · f164aa88
      est31 authored
      f164aa88
    • Scott Lamb's avatar
      add fdopendir on macOS · 322ba046
      Scott Lamb authored 
      Fixes #1017

I moved it up to src/unix/mod.rs, as it's specified in POSIX.1-2008 and
appears to be implemented on every Unix-like system.

The symbol names on macOS appear similar to those for opendir; I found
them via the commands below. I tested the x86_64 version;
fdopendir$INODE64 worked as expected.

$ nm -arch x86_64 /usr/lib/system/libsystem_c.dylib | grep fdopendir
000000000007ea6d T _fdopendir
000000000002ba97 T _fdopendir$INODE64
$ nm -arch i386 /usr/lib/system/libsystem_c.dylib | grep fdopendir
00082d1e T _fdopendir
0002b528 T _fdopendir$INODE64$UNIX2003
00082d1e T _fdopendir$UNIX2003
      322ba046
  37. Jun 04, 2018