[vlc-devel] [PATCHES] add support for arm64
remi at remlab.net
Wed Oct 9 16:36:33 CEST 2013
On Wed, 9 Oct 2013 10:54:54 +0200, Felix Paul Kühne <fkuehne at videolan.org>
>> The reality is that most packages in contribs, as well as VLC itself,
>> 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
>> two contrib packages.
>> aarch64, while rather ugly, is much easier to support than arm64
>> 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
> valid compiler argument. It requires "clang -arch arm64". This leads to
> 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
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
> (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
> would require patches to all the contrib libraries I need (that would be
> 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.
Sent from my collocated server
More information about the vlc-devel