musl - Re: [RFC PATCH 0/5] Add support to Hexagon DSP

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Sep 2023 08:19:44 -0500
From: Rob Landley <rob@...dley.net>
To: Brian Cain <bcain@...cinc.com>,
 "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
 "Matheus Bernardino (QUIC)" <quic_mathbern@...cinc.com>
Cc: Sid Manning <sidneym@...cinc.com>, Rich Felker <dalias@...c.org>,
 Fangrui Song <i@...kray.me>, Szabolcs Nagy <nsz@...t70.net>
Subject: Re: [RFC PATCH 0/5] Add support to Hexagon DSP

On 9/26/23 21:10, Brian Cain wrote:
>> *shrug* I'm making progress, but I think I need to debootstrap a newer root
>> filesystem version than the one I'm using before going much further, since you
>> then call "python3.8" as a command name and this has 3.7.3 and can't apt-get
>> anything newer without a major version update. (I'm still on devuan B and D
>> just
>> dropped, I've skipped the C release entirely. Busy with other things. Sigh, I
>> should bite the bullet...)
> 
> Tsk...sorry, clearly there's lots of room for improvement in the build script.

I'd love to get a "build all llvm targets with musl" script working, but last
time I tried it compiler-rt was an unholy abomination constructed out of spite
and special cases. (The other packages were almost reasonable.)

And then there was version skew with new package versions next time I got around
to it.

Hexagon is the one I _need_ an llvm toolchain for, but I'd LIKE an llvm
toolchain for everything. I've got a musl gcc toolchain build for the other
targets. (Layered on top of musl-cross-make, ala
https://github.com/landley/toybox/blob/master/scripts/mcm-buildall.sh because my
old https://github.com/landley/aboriginal/blob/master/cross-compiler.sh and
https://github.com/landley/aboriginal/blob/master/native-compiler.sh scripts
stayed with the last GPLv2 releases of packages until I abandoned them.)

>> Still no qemu-system-hexagon I see. When did I last poke Taylor Simpson about
>> that... 2021 it looks like:
>> 
>> https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg05062.html
> 
> Yeah, it's sadly not there yet.  We're making (glacial?) progress towards that goal.
> 
>> Thanks for the help. I'll let you know if I get it working...
> 
> I had hoped that binary builds of the toolchain might satisfy most of the
> interested parties.

I'm weird.

I'm using the Android NDK as a prebuilt binary because that thing's build is...
challenging. (Bionic hasn't _got_ a conventional standalone build I've been able
to find, and I haven't tried to reverse engineer the AOSP build to peel one out
yet.)

I may wind up using the hexagon binary toolchain, but in the context of a musl
source merge, building it from source is kind of a thing...

> But I suppose we've all read "Reflections on Trusting Trust" and understand
> the importance of being able to build it yourself.

A little more than that in my case:

  http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011898.html

I have my own project which has an agenda:

  https://landley.net/toybox/about.html

Which is a successor to an older project:

  https://landley.net/aboriginal/about.html

Which I managed to replace with a 300 line bash script that builds bootable
Linux systems for a dozen architectures:

  https://github.com/landley/toybox/blob/master/mkroot/mkroot.sh

Which you'll notice has hexagon support (lines 201-203), but the toolchain I
used to regression test that was the one I built in 2021, which was a bit of a
struggle:

  https://landley.net/notes-2021.html#28-07-2021

I did an outline of what proper documentation for that tiny system builder would
look like (it was going to be a conference talk):

  https://landley.net/talks/mkroot-2023.txt

But the best I've got so far are a couple FAQ entries:

  https://landley.net/toybox/faq.html#mkroot

  https://landley.net/toybox/faq.html#cross

  https://landley.net/toybox/faq.html#targets

So don't feel bad about not having enough documentation or newbie-proofing, I
can't exactly throw stones from my glass house either.

The hard part of documentation writing is SUMMARIZING years of work into the
"three small sticks and 4cc of mouse blood" version. If you succeed, the problem
space becomes "oh that's trivial, everyone understands that" and it looks like
you didn't do anything.

Same old same old. Still chewing on this one...

Rob

P.S. Why doesn't "cc $(find . -name '*.c') -o thingy" parallelize? You'd think
the compiler could work that out for itself somehow...
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.