You don’t need a ARM machine to build a library for ARM. I have
successfully built other libraries (OpenSSL, yaml-cpp, lz4, etc.) for ARM.
The key difference is that those libraries use CMake, and it’s
straight-forward to build for x86_64 and arm64 using:
*cmake ..
There's both Intel-specific and ARM-specific code in the library.
I don't have an ARM machine, so can't test it, but I'm pretty sure Jeffrey
built it on ARM successfully (probably on Linux, since so far there is no ARM
Mac).
My suspicion is - you're building it on Intel, so the stuff that
The problem is not even with the “fat” binaries. I can’t even compile the
library on arm64. There are some Intel-specific code in the library (ie.,
in cpu.h if you look at my original post).
On Fri, Oct 16, 2020 at 12:11 AM Uri Blumenthal wrote:
> IMHO, having a fat library is bad idea because
IMHO, having a fat library is bad idea because it doesn't seem to work well fur
the last several years. Wasting space is another reason.
IMHO, you're better off recompiling once you get the new ARM-based Mac. Keep
x86_64 stuff on Intel (don't drag it to ARM), and build ARM-only stuff on ARM.
Thanks for the quick reply.
I currently use Crypto++ in an application. The application is MacOS only.
Since Apple is switching to Arm-based MacOS machines, I need to support
both Intel and Arm CPUs. Essentially, I would need the Crypto++ built for
x86_64 and arm64 (if I want to run natively