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.kau...@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 <mva...@gmail.com> wrote:
Op zo 18 sep. 2022 om 16:06 schreef brianw <bri...@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@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
