A dylib using mio on mac os x exports symbols that it probably should not.

[SirVer]

This made well be a rust compiler bug, I am not sure. I made a small repro case here: https://github.com/SirVer/mio_crash_test_link_mac_os (< 20 lines of code). In there, we make a dylib with one function:

#[no_mangle]
pub extern "C" fn connect() {
    println!("In connect.");
    let _ = UnixSocket::stream().unwrap().connect("/tmp");
}

and we call it through a python file using ctypes. This results in an infinite recursion, because the call to UnixSocket...connect() actually calls this connect function again. Renaming our function from connect to blub makes the test.py script run through without error.

This error does not happen on Linux, but it is very reproducible on Mac OS X. Here are reproduction steps:

git clone git@github.com:SirVer/mio_crash_test_link_mac_os.git
cd mio_crash_test_link_mac_os
cargo build
./test.py

This results in this stack trace:

81:        0x1013bded8 - connect
  82:        0x10140eb23 - sys::socket::connect::he0ea770b1bff1135CDe
  83:        0x1013d89ac - sys::unix::net::connect::h7ad423c2217ecc439Ic
  84:        0x1013be3f0 - sys::unix::uds::UnixSocket::connect::h6827222311190699873
  85:        0x1013be028 - net::unix::UnixSocket::connect::h9827995218443730593
  86:        0x1013bdf87 - connect::__rust_abi
  87:        0x1013bded8 - connect

This was discovered while live coding on the Swiboe stream while writing this commit. Has anybody an idea how to avoid name clashes like these?

[carllerche]

This is most likely a rust issue. I will try to ping some people

[carllerche]

Ah, so I misunderstood the case. This is actually expected behavior. When you define a connect function w/ no_mangle you are actually ghosting the libc connect function (linkers on different platforms behave a bit differently).

If you are going to define functions w/ no_mangle you probably want to prefix them. swiboe_connect or something.

So, closing with "expected behavior" :)

[SirVer]

That is what I did in the end. Actually, it occurred to me while coding on stream that this is actually the behavior I would expect from a C library. But shouldn't the rust linker not warn about duplicate symbols?

[tomjakubowski]

There's an issue for that! rust-lang/rust#28179

[tomjakubowski]

Well, sort of. In the typical case libc is dynamically linked; in that case I'm not sure how the Rust linker could warn about such a symbol collision. In some cases it might even be intentional (e.g. if a library wishes to override libc's malloc/free).