[QNX] Failure to link with std on QNX 8.0

[tronical]

I tried this code:

fn main() {
}

I expected to see this happen: Compiles.

Instead, this happened: Linking fails with this:

error: linking with `qcc` failed: exit status: 1
  |
  = note:  "qcc" "-Vgcc_ntoaarch64le_cxx" "/tmp/rustcdYZPCb/symbols.o" "<6 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/aarch64-unknown-nto-qnx800/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lc" "-lm" "-lsocket" "-lregex" "-L" "/tmp/rustcdYZPCb/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-o" "/home/simon/src/qnx-test/target/aarch64-unknown-nto-qnx800/debug/deps/qnx-test-fbbe5a782bfd11a8" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /home/simon/qnx/qnx800/host/linux/x86_64/usr/bin/aarch64-unknown-nto-qnx8.0.0-ld: /home/simon/src/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/aarch64-unknown-nto-qnx800/lib/libstd-06a16e12f5d93859.rlib(std-06a16e12f5d93859.std.59a1aa632481cede-cgu.10.rcgu.o): in function `std::sys::backtrace::_print_fmt::{{closure}}':
          std.59a1aa632481cede-cgu.10:(.text._ZN3std3sys9backtrace10_print_fmt28_$u7b$$u7b$closure$u7d$$u7d$17h7223c4412795f075E+0x90): undefined reference to `__my_thread_exit'
          /home/simon/qnx/qnx800/host/linux/x86_64/usr/bin/aarch64-unknown-nto-qnx8.0.0-ld: std.59a1aa632481cede-cgu.10:(.text._ZN3std3sys9backtrace10_print_fmt28_$u7b$$u7b$closure$u7d$$u7d$17h7223c4412795f075E+0x94): undefined reference to `__my_thread_exit'

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-
link-lib)

If I comment out the __my_thread_exit related code in library/std/src/sys/backtrace.rs the program links and everything runs as expected (my real app, not just the above dummy main).

Meta

rustc --version --verbose:

rustc 1.89.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.89.0-dev
LLVM version: 20.1.7
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s

(This is, in fact, the master branch built from commit 2fcf177 )

[workingjubilee]

(This is, in fact, the master branch built from commit 2fcf177 )

then it should say that, despite being -dev? weird.

[workingjubilee]

cc @jonathanpallant @japaric @gh-tr @flba-eb Your target seems borked, sorry about the collateral from whatever broke it.

[flba-eb]

Thanks for letting me now, @workingjubilee!
As one can see in rustc book (nto support), std is not supported yet for QNX 8.0.
I'm aware of two groups of persons working on 8.0 std support, I will contact them on Monday. Let's keep this ticket open for one or two weeks as it could help for communication.
Regarding the missing symbol of __my_thread_exit, I guess this is one of the many quirks you see when supporting different QNX versions. Rust-Libc is also missing 8.0 support!

[flba-eb]

I think all you need is an empty #[no_mangle] fn __my_thread_exit(value_ptr: *mut *const c_void) {} to make the linker happy. To quote libc:

Function on the stack after a call to pthread_create(). This is used
as a sentinel to work around an infitnite loop in the unwinding code.

Alternatively you could hack-remove the loop detection in backtrace code to remove this dependency -- this is probably going to break the backtracing (which could be broken on 8.0 anyway).

[workingjubilee]

oh, my bad. I reviewed that PR even

[MarkSchmitt]

@tronical I've been toying around with compiling for QNX 8 and ran into the same issue, and my (possibly completly hacky) solution is to disable part of the backtrace for QNX 8 (or rather: only enable it on older versions)
master...MarkSchmitt:rust:feature/experimental_qnx800_support

But I haven't understood the infinite loop error ... but producing backtraces work, so it's not completly broken I think.

I haven't opened a PR yet because I'm not convinced this is the only problem, also I haven't read the contribution guidelines for the rust compiler yet 🤦 ...

After that I tried runnig the test-suite, which fails with two error-classes:

1. Address family not supported for network tests because my QNX 8 x86_64 VM does not support IPV6 O_o - once I worked around that and disabled ipv6 for nto8 those tests passed (with ipv4 only)
2. the symlink tests fail, but they also fail when I try to create a symlink file locally (f.e. ln -s /absolue/path /some/otherpath) - but only for absolute paths, relative symlinks work ... I haven't had time yet to investigate whether there is a bug in QNX .. but I couldn't find any notes in the release notes for qnx 8.0.1 and 8.0.2 .. and I think I stil have an older version, so I'll try to update and see that problem is fixed ...

That all being said, I am able to build and run a simple tokio / async / axum webserver application on QNX 8 in the x86_64 VM. And it does server http requests (just something I wanted to see...). So in principal, something is working, but I don't have much confidence yet.

I've had trouble getting the QNX 8 Arm64 image running on my RPi4 properly .. if it boots, I can't switch to a terminal and also it does not relyably get an ipaddress via DHCP.

I also looked into compiling and running the libc tests, but I was having trouble compiling them, the c_enum macros are not properly build and/or are causing compile time issues.

[AkhilTThomas]

@tronical I've been toying around with compiling for QNX 8 and ran into the same issue, and my (possibly completly hacky) solution is to disable part of the backtrace for QNX 8 (or rather: only enable it on older versions) master...MarkSchmitt:rust:feature/experimental_qnx800_support

But I haven't understood the infinite loop error ... but producing backtraces work, so it's not completly broken I think.

I haven't opened a PR yet because I'm not convinced this is the only problem, also I haven't read the contribution guidelines for the rust compiler yet 🤦 ...

After that I tried runnig the test-suite, which fails with two error-classes:

1. Address family not supported for network tests because my QNX 8 x86_64 VM does not support IPV6 O_o - once I worked around that and disabled ipv6 for nto8 those tests passed (with ipv4 only)
2. the symlink tests fail, but they also fail when I try to create a symlink file locally (f.e. ln -s /absolue/path /some/otherpath) - but only for absolute paths, relative symlinks work ... I haven't had time yet to investigate whether there is a bug in QNX .. but I couldn't find any notes in the release notes for qnx 8.0.1 and 8.0.2 .. and I think I stil have an older version, so I'll try to update and see that problem is fixed ...

That all being said, I am able to build and run a simple tokio / async / axum webserver application on QNX 8 in the x86_64 VM. And it does server http requests (just something I wanted to see...). So in principal, something is working, but I don't have much confidence yet.

I've had trouble getting the QNX 8 Arm64 image running on my RPi4 properly .. if it boots, I can't switch to a terminal and also it does not relyably get an ipaddress via DHCP.

I also looked into compiling and running the libc tests, but I was having trouble compiling them, the c_enum macros are not properly build and/or are causing compile time issues.

AFAIK __my_thread_exit does not exist anymore in the qnx 8.0 library. I had a basic port running but unfortunately couldn't spend much time on it. The bulk of the change required is in the libc repo as most the API signatures are different.
The IPV6 issue is that the AF_INET6 define is different!