Running an app linked with a C library fails on Mac ARM

1

I have just migrated from Intel to Arm Mac. Running an application built/linked with an external C code, that worked like a charm on Intel, fails now on ARM with:
dyld: Library not loaded, no such file /System/Library/Frameworks/Security.framework/Versions/A/Security

Removing rustc-link-lib and #[link(name = ... from the code makes the app run.
I have even installed Xcode to be sure nothing is missing in the dev stack.
This is the case with rust installed both with brew and curl.

If otool would help:
otool -L .cargo/bin/cargo
.cargo/bin/cargo:
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61123.121.1)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2503.1.0)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)

Nothing fancy here, Sequoia 15.3.1:
mysql = "25.0.1"
mysql_common = { version = "0.32.4", features = ["chrono"] }
chrono = "0.4.38"
num-traits = "0.2"
num-derive = "0.3"
rand = "0.8.5"
hungarian = "1.1.1"
config = "0.13.1"
serde = "1.0.140"
log4rs = "1.1.1"
log = "0.4.8"

2

What is the content of your build script and what is the #[link(name = "...")] definition you used?

3

#[link(name = "dynapool")] because the lib is libdynapool.a
Buildscript = cargo.toml? You can see most of it above, two lines more (the second in profiles):
edition = "2021"
opt-level = 3

One more difference - on Intel I just copied the lib to a system directory. On Arm I run cargo with RUSTFLAGS='-L ..' environment variable. The linking works fine.

I think the problem is already visible with "otool" - it shows a path that does not exist on Arm (I don't know if it existed on my Intel Mac)

4

No, build.rs. The file where you put rustc-link-lib.

That is a completely different library than what the error complains about. It complains about a dylib in Security.framework not being found. What is causing it to be linked?

5

SOLVED: well, I have not called routines in the external library yet but the error is gone. Solution - shared library

6

The problem might originate in memory allocation - I get exactly the same (thus misleading) message in run time (.../A/Security no such file) when I try to allocate big static arrays. Most depressing - these big static arrays take only 10% of memory available.

7

I have found the cause now, with the help of GCC - ... of array '...' exceeds maximum object size '2147483647'. clang LLVM gives you random errors like '/usr/lib/libSystem.B.dylib' (no such file), a disappointment brought about by Arm Mac. Now I have to rewrite my software, which needs big arrays of objects for its "dynamic programming" algorithm, maybe try array of pointers, which might affect performance.