[Toybox] scripts/llvm-buildall.sh?

[Patrick Oppenlander]

On Wed, Aug 4, 2021 at 8:53 PM Rob Landley <rob at landley.net> wrote:
>
> On 8/3/21 7:05 PM, Patrick Oppenlander wrote:
> >> What I'd LIKE to do is create a scripts/llvm-buildall.sh that builds all the
> >> supported musl+llvm targets the way mcm-buildall.sh does for musl+gcc. And
> >> getting llvm-project itself to do that was pretty straightforward (it builds
> >> them all by default). But clang-rt depends on the target libc headers being
> >> there first (...why?) and then the invocation is... yeah.
> >
> > I mentioned on the musl list that I've had a go at this too.
>
> Dig dig dig...
>
>   https://www.openwall.com/lists/musl/2021/07/26/3
>
> Ooh, very nice. Thanks.
>
> > Getting the llvm project & musl to play nice together is a pain. In
> > case you missed it, what I came up with is here:
> >
> > https://github.com/apexrtos/musl-cross-make/blob/clang/litecross/Makefile.clang
>
> Let's see...
>
> I made it to the giant span of "foreach" starting on line 49 and had to stop for
> health reasons.

If you want the llvm build system to build multiple builtin or runtime
targets there's a lot of configuration required :(

There's a bunch of cmake "caches" in the llvm project which set a
bunch of these variables for some canned configurations (e.g. see
llvm-project/clang/cmake/caches/BaremetalARM.cmake).

But yes, I should probably use a single foreach there though. Not
really sure why I did it like that.

> > Glossing over the finer details this basically boils down to:
> > * configure llvm
> > * do an llvm "distribution" build
> > * configure musl
> > * install musl headers
> > * do an llvm "builtins" build
>
> The builtins depending on the libc headers is outright disgusting. (This does,
> however, imply that they don't depend on the LINUX headers, which is... My brain
> hurts.)

That's a definite WTF.

> The next question is, of course, WHY compiler-rt depends on the libc headers.
> And if it's GOING to depend on a header file:
>
> https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h
>
> Says it's MIT licensed right at the top...

Nice. They'd need something similar for 15 other OS targets though.

Still, depending on the C library headers seems completely broken.

> By the way, I tried to subscribe to the llvm-dev mailing list but
> https://lists.llvm.org/mailman/listinfo/llvm-dev is disabled and emailing that
> subscribe@ thing multiple times has not gotten a response. That development
> community is approximately as welcoming to outsiders as xfree86 was.

You're telling me.

I've submitted a bunch of patches to phabricator which are in various
states of landed (their word for merged), accepted (waiting for..
something?), and bikeshedding.

I've given up beating my head against it for now and am currently
rebasing this list whenever they release something:

https://github.com/apexrtos/musl-cross-make/tree/clang/patches/llvm-project-12.0.1.src

> > * build musl
> > * install kernel headers
> > * do an llvm "runtimes" build
> >
> > I also create symlinks & config files so that it looks like a normal
> > gcc style toolchain.
>
> The kernel needs to learn that $CROSS-cc is a good compiler name, and $CROSS-gcc
> is not. And:
>
>   https://github.com/torvalds/linux/blob/v5.13/Makefile#L434
>
> Is just painful. Unfortunately, I'm not sure how you'd say "use the first of
> ${CROSS_COMPILE}{clang,gcc,cc} that exists" in Makefile syntax. The foreach
> stuff expands ALL of them, doesn't seem to have a "break" construct. (And of
> course musl does it in shell script, which is the sane way to do it. :)

It's even worse because llvm doesn't install symlinked binaries, so to
use clang you need to "clang --target=arm-xxx" ala

https://github.com/torvalds/linux/blob/62fb9874f5da54fdb243003b386128037319b219/Makefile#L578

I work around that in my build by constructing symlinks and .cfg files
to make clang look like a traditional triple prefixed toolchain.

> > It would be nice if there was one well maintained place to go for an
> > llvm/musl build recipe.
>
> I dunno about "well maintained" but if I can get it to work I'm happy to provide
> a script, and possibly even host binaries although a gigabyte tarball is a bit
> of a stretch for my hosting...

I think my mcm fork should do what you need, but I know you prefer
more minimal solutions to these problems.

Patrick