Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Jul 2014 11:58:59 -0700
From: "Weiming Zhao" <>
To: <>
Subject: RE: AArch64 merge back

Hi Rich,

Thanks a lot for your response.

We're trying static linking of AArch64 with some simple tests.
Some simple tests are working, but we do see some syscall issue as you
We suspect it's related with arch/aarch64/bits/syscall.h.
Is the file written from scratch or based on some existing open source


-----Original Message-----
From: Rich Felker [] On Behalf Of Rich Felker
Sent: Tuesday, July 01, 2014 11:25 AM
Subject: Re: [musl] AArch64 merge back

On Tue, Jul 01, 2014 at 10:41:10AM -0700, Weiming Zhao wrote:
> Hi Isaac,
> So if I just want to use some arch-independent functions, then I just 
> need to build the main musl repo with aarch64 compiler. Is my 
> understanding correct?

No. I didn't really understand what you were asking before, but it might be
more clear if you read the porting documents on the wiki.
Rather than trying to answer point by point I'll try to explain a few

It's not possible to use musl on a new arch simply by compiling the
arch-independent C. This is partly because there are a number of components
of libc that fundamentally cannot be expressed in C, and partly because the
kernel (gratuitously) has a different set of constants, struct definitions,
etc. for each architecture.

Generally ports are not merged (in the "git merge" sense) because most of
the early work on them is a mess of incompleteness, trial-and-error, etc.
Also merging would be a lot of work since we normally rebase all merges,
whereas master has often diverged quite a bit before a port is ready to
merge. Instead, once the port is working, we usually just add it as a single
commit, followed by any fixes for issues that weren't found before commit.

I'm not clear on the status of the aarch64 port right now. It was stalled
for a while because of changes needed in many of the arch-independent files
to accomodate the way the kernel does things on newer archs (omitting lots
of simple syscalls that can be emulated using more complex ones). That work
is done in mainline musl now though, so it's no longer blocking ports.
Further progress is up to the people working on those ports (or anyone else
who wants to build on their work). I'm really hoping it will be finished
during this release cycle so we can have aarch64 support in 1.1.4.

If you or anyone else wants to play around with trying to get it to work
based on the in-progress ports, the best approach would be to simply copy
over the new files added in the aarch64 musl git tree into a more recent
musl (1.1.2 or later).


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.