Cross compile on aarch64 from MacOS/darwin to aarch64-unknown-linux-musl is failing with undefined symbol: readdir64 about cargo-zigbuild HOT 7 CLOSED

@reubenmiller IMO it should be easy to fix by adding more LFS64 functions to

Happy to accept a PR to do that.

from cargo-zigbuild.

I have managed to figure out this, I did miss some symbols in my PR #172:

nm ~/.rustup/toolchains/1.71.1-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-493936ddc336b3cf.rlib | grep "64$"
nm: lib.rmeta: no symbols
                 U fstat64
                 U fstatat64
                 U ftruncate64
  ......
                 U lseek64
                 U lstat64
                 U open64
                 U pread64
                 U pwrite64
                 U readdir64
                 U stat64

At least these are the symbols needed.
And for 1.72.0, aka stable:

nm ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd-aa8203b3ba116fbe.rlib | grep "64$"
nm: lib.rmeta: no symbols
0000000000000000 r GCC_except_table164
   ......

It would be better to have a test for this regression.

from cargo-zigbuild.

cc @haohaolee Looks like the weak symbol list isn't complete?

https://github.com/search?q=repo%3Abminor%2Fmusl%20_LARGEFILE64_SOURCE&type=code

from cargo-zigbuild.

I can confirm that the build experienced will be fixed once #180 is merged.

from cargo-zigbuild.

I wanted to be conservative so I tried to modify as few symbols as possible in #172, I was afraid that too many adds lead to other issues.

Hi @reubenmiller does your project rely on libc crate? as far as I know, some symbols like readdir64 are referenced in libc crate, and the latest libc crate has already fixed this issue.

Please let me know if this is the case, thanks

from cargo-zigbuild.

I wanted to be conservative so I tried to modify as few symbols as possible in #172, I was afraid that too many adds lead to other issues.

Hi @reubenmiller does your project rely on libc crate? as far as I know, some symbols like readdir64 are referenced in libc crate, and the latest libc crate has already fixed this issue.

Please let me know if this is the case, thanks

No we don't use anything from the libc crate, we use musl builds for portability reasons.

from cargo-zigbuild.

@reubenmiller No worries. Ignore me, I was asking a wrong question. I have checked your build and I think I have a better understanding now, this issue has nothing to do with the libc crate.

In short, you need to satisfy those undefined symbols in std, e.g. U readdir64

ps: musl is a kinda libc, and your project does depend on libc crate if you check the Cargo.lock

from cargo-zigbuild.