[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flac-dev
Subject:    Re: [flac-dev] Enabling universal building of libFLAC
From:       Martijn van Beurden <mvanb1 () gmail ! com>
Date:       2022-09-19 6:37:24
Message-ID: CADQbU68TbWhVzxV-U5wYrgjBRYHBF-qNRXs6=ZfpRwxpen1BuQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Op zo 18 sep. 2022 om 19:08 schreef Robert Kausch <robert.kausch@freac.org>:

> As an integrator targeting four different architectures on Mac (ppc,
> x86, x86-64 and aarch64), I build all the libraries separately for each
> architecture and then combine the resulting binaries into a universal
> binary using the lipo tool.
>
> That's the standard way to build universal binaries when dealing with
> Autotools or CMake build systems. It's quick and easy, so I don't really
> see a need for supporting one-step universal binary builds.
>

Thanks for enlightening me. This doesn't have as high a priority as I
thought it had then.


> Preprocessor defines for different architectures are mostly standardized
> and should work on all systems (no need to use Apple-specific defines).
> Microsoft uses a different scheme, though, as expected... And of course
> there may be the usual bunch of embedded toolchains doing non-standard
> things.
>

Yes, the more I change, the more things I'll probably break.


> During a one-step universal binary build, the different instances of the
> compiler define the correct macros for the respective architecture being
> compiled. No need to work around any build-system logic doing its own
> thing.
>

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.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op zo 18 \
sep. 2022 om 19:08 schreef Robert Kausch &lt;<a \
href="mailto:robert.kausch@freac.org">robert.kausch@freac.org</a>&gt;:<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&#39;s the standard way to build universal binaries when dealing with <br>
Autotools or CMake build systems. It&#39;s quick and easy, so I don&#39;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&#39;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&#39;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&#39;t work because \
the x86_64 compiler complains and the detection of x86intrin.h doesn&#39;t work \
because the aarch64 compiler complains. So, configuration needs to be aware of this \
too.<br></div></div></div>



_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev


[prev in list] [next in list] [prev in thread] [next in thread]