<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op zo 18 sep. 2022 om 19:08 schreef Robert Kausch <<a href="mailto:robert.kausch@freac.org">robert.kausch@freac.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As an integrator targeting four different architectures on Mac (ppc, <br>
x86, x86-64 and aarch64), I build all the libraries separately for each <br>
architecture and then combine the resulting binaries into a universal <br>
binary using the lipo tool.<br>
<br>
That's the standard way to build universal binaries when dealing with <br>
Autotools or CMake build systems. It's quick and easy, so I don't really <br>
see a need for supporting one-step universal binary builds.<br></blockquote><div><br></div><div>Thanks for enlightening me. This doesn't have as high a priority as I thought it had then.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Preprocessor defines for different architectures are mostly standardized <br>
and should work on all systems (no need to use Apple-specific defines). <br>
Microsoft uses a different scheme, though, as expected... And of course <br>
there may be the usual bunch of embedded toolchains doing non-standard <br>
things.<br></blockquote><div><br></div><div>Yes, the more I change, the more things I'll probably break.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

During a one-step universal binary build, the different instances of the <br>
compiler define the correct macros for the respective architecture being <br>
compiled. No need to work around any build-system logic doing its own thing.<br></blockquote><div><br></div><div>There are a few things in build-system logic that need to be circumvented too, it seems. As I understand, in a x86_64 + aarch64 universal build, detection of A64 NEON intrinsics doesn't work because the x86_64 compiler complains and the detection of x86intrin.h doesn't work because the aarch64 compiler complains. So, configuration needs to be aware of this too.<br></div></div></div>