For some reason, this linker issue began to appear in the parent branch on Mac (not on Linux):
= note: ld: warning: ignoring duplicate libraries: '-lc', '-lm'
ld: warning: object file (/Users/x/athena/target/debug/deps/libblake3-6dd7f4fd8fb13142.rlib[6](db3b6bfb95261072-blake3_neon.o)) was built for newer 'macOS' version (14.4) than being linked (14.0)
Undefined symbols for architecture arm64:
"__end", referenced from:
_sys_alloc_aligned in libathena_vm-f3496fa413e47695.rlib[32](athena_vm-f3496fa413e47695.eqbvo55faxs9zik4al4vfwnll.rcgu.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: could not compile `athena-vmlib` (lib) due to 1 previous error
Note that the warnings are red herrings; the real issue is this missing "__end" symbol.
Here's an explanation of the fix:
The -undefined dynamic_lookup flags:
On macOS, the linker is stricter by default about undefined symbols.
These flags tell the linker to allow undefined symbols and to look them up dynamically at runtime.
This is particularly relevant for the __end symbol that was causing the original error.
Why it works:
The __end symbol, which is used in your sys_alloc_aligned function, is typically defined by the linker.
On macOS, this symbol might not be available at link time, causing the original error.
By allowing dynamic lookup, you're telling the system to resolve this symbol when the program runs, rather than when it's compiled.
Difference from default behavior:
By default, macOS tries to resolve all symbols at link time for safety and performance reasons.
This stricter behavior can cause issues with code that relies on symbols that are only available at runtime or in the final executable.
Why it's needed for your project:
Your code uses the __end symbol, which is typically provided by the runtime environment.
This symbol might be defined differently or handled differently on macOS compared to other systems.
Potential implications:
While this solves the immediate problem, it's worth noting that allowing undefined symbols can potentially lead to runtime errors if the symbols are truly missing.
In your case, it's likely safe because __end should be provided by the runtime environment.
For some reason, this linker issue began to appear in the parent branch on Mac (not on Linux):
Note that the warnings are red herrings; the real issue is this missing "__end" symbol.
Here's an explanation of the fix:
The -undefined dynamic_lookup flags:
On macOS, the linker is stricter by default about undefined symbols. These flags tell the linker to allow undefined symbols and to look them up dynamically at runtime. This is particularly relevant for the __end symbol that was causing the original error.
Why it works:
The __end symbol, which is used in your sys_alloc_aligned function, is typically defined by the linker. On macOS, this symbol might not be available at link time, causing the original error. By allowing dynamic lookup, you're telling the system to resolve this symbol when the program runs, rather than when it's compiled.
Difference from default behavior:
By default, macOS tries to resolve all symbols at link time for safety and performance reasons. This stricter behavior can cause issues with code that relies on symbols that are only available at runtime or in the final executable.
Why it's needed for your project:
Your code uses the __end symbol, which is typically provided by the runtime environment. This symbol might be defined differently or handled differently on macOS compared to other systems.
Potential implications:
While this solves the immediate problem, it's worth noting that allowing undefined symbols can potentially lead to runtime errors if the symbols are truly missing. In your case, it's likely safe because __end should be provided by the runtime environment.