[vlc-devel] [PATCHES] add support for arm64

[Rémi Denis-Courmont]

   Hello,

On Wed, 9 Oct 2013 10:54:54 +0200, Felix Paul Kühne <fkuehne at videolan.org>
wrote:
>> The reality is that most packages in contribs, as well as VLC itself,
>> are
>> based on autotools, or otherwise use compatible triplets. You cannot
>> pass the
>> same architecture for AArch64 as you would for AArch32, if only because

>> AArch32 still needs to be supported. This is not only about NEON
support
>> in
>> two contrib packages.
>> 
>> aarch64, while rather ugly, is much easier to support than arm64
because
>> it
>> does not match "arm*". And that is what ARM, LLVM and GCC specify. In
>> the long
>> term though, it is likely that configure scripts need to support both.
> 
> This is technically absolutely correct. Regrettably, I stumbled across 2
> limitations which lead to the current approach. "clang -arch aach64" is
no
> valid compiler argument. It requires "clang -arch arm64". This leads to
a
> arm64-apple-darwin13 dump machine string. 

There are three separate "issues" here: the value of $(ARCH) in contrib,
the host triplet, and the clang compilation flags.

$(ARCH) is a contrib-internal convenience for conditional build rules. We
can use "arm64" if we want; it just needs a trivial patch to the
get-arch.sh script to add that "new" architecture. However, you should
probably not assume that our $(ARCH) matches clang's naming convention or
anything else's for that matter, but that too is fairly trivial.

However, the host triplet is a big deal. A triplet that matches "arm*-*"
may trigger plenty of assumptions that AArch64 does _not_ fulfill, such as
an LPI32 ABI, ARMv4 assembler, ARM preprocessor predefined macros,
ARM-specific compiler and linker flags, ARM-specific executable file format
extensions, etc. And in some case, this will generate silently broken code
rather than an obvious build failure. In that respect, using "arm-foo-bar"
for AArch64 should be proscribed, and "aarch64-*-*" would be much safer
than "arm64-*-*". 

In an ycase, GCC specifies aarch64-*-*, and I expect most contrib
libraries to follow that convention.

> However, this is string isn't recognized by virtually all contrib
packages
> (with the notable exception of libav btw.), so if I don't merge the
> proposed patch set, the proper solution (which it would be without a
doubt)
> would require patches to all the contrib libraries I need (that would be
13
> minus libav atm) adding arm64 detection.
> Not sure you'd like that :)

In most cases, config.guess/config.sub needs to be refreshed. In some
cases, the build system really needs updating.

-- 
Rémi Denis-Courmont
Sent from my collocated server