|
Message-ID: <2e355ec7-58f9-c82f-7889-504ea5f34b2f@landley.net> 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...
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.