[flac-dev] Enabling universal building of libFLAC

[Robert Kausch]

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.

Basically, with the latter, you'll never know if anything will be broken 
on some architecture unless there is no configure step for the 
respective project or you're dealing with your own code. Many things can 
go wrong. It's not only about architecture macros, but also about 
different integer type sizes (many projects detect those in configure 
scripts), byte-order etc.

That said, if you really want to support one-step universal binary 
builds of FLAC, the main issue probably are the currently used 
architecture macros. Those could be set by an architecture.h header, 
though. It should not be necessary to detect the architecture during 
configuration.

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.

Here are some of the most common, the _M_xxx ones are Microsoft-specific:

    x86: __i386__ or _M_IX86
    x86-64: __x86_64__ or _M_AMD64
    ARM: __arm__ or _M_ARM
    aarch64: __aarch64__ or _M_ARM64
    MIPS: __mips__
    PPC: __ppc__
    PPC64: __ppc64__
    RISC-V: __riscv

I got most of these from this page, which, however, is a bit outdated 
now: https://sourceforge.net/p/predef/wiki/Architectures/
The Microsoft-specific macros are documented here: 
https://learn.microsoft.com/cpp/preprocessor/predefined-macros (there 
are more, like _M_ALPHA and _M_PPC, though, which are no longer documented)

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.

Robert

----
Robert Kausch
robert.kausch at freac.org

Am 18.09.2022 um 16:39 schrieb brianw:
> Ah, yes, the preprocessor defines. Now I see what you're talking about. Those are crucial because there is often code specific to a particular architecture.
>
> NeXT and Apple have supported up to four-processor multi-architecture builds since the nineties. I don't know whether they modified the compiler to do this, or what. But the standard practice is to learn the #define values that signal a specific architecture, and work with those. At no time would a NeXT/Apple developer manually set these preprocessor defines, nor would the make process. The tools allow a list, and the compiler is called repeatedly, each time with the preprocessor values set appropriately.
>
> If these values differ from the ones that libFLAC is already using (and they almost surely are spelled differently, or have more or fewer underscores), then perhaps a macOS section in a common header (like config.h) would be needed to read the Apple-supplied preprocessor values and then set the corresponding "FLAC" compatible values. Even if this works, it would probably require defeating any Make logic that hard-codes those values (otherwise the build would still be stuck with one architecture).
>
> I recall that `configure` has long supported NeXT and Mac OS X, but I do not recall whether anyone has shipped an open-source product that can build multi-architecture. Hopefully, someone has done this, somewhere, and their setup could be used as an example.
>
> It's possible that I've always punted, built for each architecture separately, and then manually combined the architectures into a single segmented loader file (whatever the official name for that is, and the format has changed since NeXT, of course). I hope it's not still like that. ;-)
>
> Brian
>
>
> On Sep 18, 2022, at 4:19 PM, Martijn van Beurden <mvanb1 at gmail.com> wrote:
>> Op zo 18 sep. 2022 om 16:06 schreef brianw <brianw at audiobanshee.com>:
>>> When you refer to "runtime variables," do you really mean build time?
>> Yes, build time. That was formulated wrong.
>>
>>> I would assume that the source code does not need to change in order to support multiple architectures on macOS, but the compiler and/or make options may need to change.
>> What I mean by changing code is mostly changing preprocessor defines. Certain code is included or excluded from compilation by the preprocessor based on defines that use variables set or unset by the configure or CMake configuration. However, if these decisions need to be made at build time instead of at configuration time for MacOS, these preprocessor defines needs to change, hence the source code needs to change.
>>
>> It might be possible to not touch the code by solving this in config.h for CMake. In CMake config.h one can add conditional statements. I'm unsure whether that is also possible for configure.
>>
>> One could choose to support universal building only through CMake, as this seems to easier to solve.
>>   
>>> I have not dug into the details yet. If someone does not find a solution before I get back from vacation, I'll take a look. Usually, Xcode makes this easy, and Xcode even produces a Makefile that works outside of the GUI Xcode.app (i.e. it supports command-line building), so that might be a reasonably quick option. However, I admit that keeping Xcode files up to date - like any other GUI build environment - might not be worth the effort, but at least the Makefile could be useful.
>> It could be such a Makefile provides clues on how and where to change the build system as it is, yes.
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev