[PATCH] gnu: Add cross-clang.

Hi Guix!

This small patch series adds cross-clang, a cross-compiler version of

clang. Clang doesn't really make a distinction between a native and a

cross-build, it is already a cross-compiler, but this ensures that:

1. it actually works

2. it targets (%current-target-architecture) by default

The rest of the series ensures that libcxx and libcxxabi can be

cross-compiled with it.

---

gnu/packages/llvm.scm | 21 +++++++++++++++++++--

1 file changed, 19 insertions(+), 2 deletions(-)

---

gnu/packages/llvm.scm | 125 +++++++++++++++++++++++++++++++++++++++++-

1 file changed, 124 insertions(+), 1 deletion(-)

cross-compilation. Move llvm to...

[inputs]: ...here.

[arguments]: adjust CROSS_INCLUDE_PATH when cross-compiling.

(libcxx-6)[native-inputs]: Use cross-clang for cross-compilation. Move

llvm to...

[inputs]: ...here.

---

gnu/packages/llvm.scm | 29 ++++++++++++++++++++++-------

1 file changed, 22 insertions(+), 7 deletions(-)

cross-compilation. Move llvm and libcxx to...

[inputs]: ...here.

[arguments]<adjust-CPLUS_INCLUDE_PATH>: Also adjust

CROSS_CPLUS_INCLUDE_PATH when necessary.

---

gnu/packages/llvm.scm | 41 ++++++++++++++++++++++++++++++++++-------

1 file changed, 34 insertions(+), 7 deletions(-)

(libcxxabi-6): Inherit from it.

---

gnu/packages/llvm.scm | 72 +++++++++++++++++++++++++++++++------------

1 file changed, 53 insertions(+), 19 deletions(-)

Julien Lepiller schreef op do 03-03-2022 om 17:02 [+0100]:

Do you mean (%current-target-system)?

Also, WDYT of making 'cross-clang' a memoising procedure, such

that there's only one package object for a cross-clang of a fixed

target system (and version)?

Probably a few other packages built with clang need such a thing as well.

How about making doing the right thing a bit easier? Suggestion: introduce

a 'clang-for-target' procedure, automatically returning the right clang:

(define (clang-for-target #:optional (clang clang))

(if (%current-target-system)

(cross-clang [...])

clang)) ; not cross-compiling

then packages just need to do

(native-inputs (list (clang-for-target) libfoo libbar ...))

The rest of the series ensures that libcxx and libcxxabi can be

cross-compiled with it.

Customarily, cross-compilers are named $TARGET-foo. WDYT of

renaming the clang binary to '$TARGET-clang', such that a package

can have both a native clang and a cross-clang in native-inputs if desired?

Also, Autoconf looks for $TARGET-compiler, where compiler is at least gcc,

but possibly also clang

And perhaps the package name can be changed '$TARGET-clang' like done for gcc?

Upstream clang doesn't, but this is in a 'cross-clang' procedure,

so I think it would make sense for Guix' cross-clang to ignore

LIBRARY_PATH and only use CROSS_LIBRARY_PATH. Mixing up

C_INCLUDE_PATH and CROSS_C_INCLUDE_PATH (& friends) is unlikely

to lead anything good, e.g. include/bits/setjmp.h is architecture-dependent.

I don't think Guix does a "lib" / "lib64" split, "lib" might

be sufficient. At least, there are a few comments like

;; Force powerpc libdir to be /lib and not /lib64

in Guix (though the gcc packages still includes "lib64" but

maybe that's only due to historical reasons).

How does this patch series interact with 'with-c-toolchain'?

Would "guix build hello --target=aarch64-linux-gnu --with-c-toolchain=..."

succesfully compile 'hello' with clang?

Greetings,

Maxime.

Le Thu, 03 Mar 2022 17:40:36 +0100,

Maxime Devos <maximedevos@telenet.be> a écrit :

yes, that's what I meant.

I don't know how to do that. Are there some examples around?

Great idea, I implemented that procedure.

I can do that, but I don't think it'll be recognized by cmake. It's

building right now, and I'll have a try.

OK, fixed.

I saw that in GCC, so I just used the same specification, but just

'("lib") is fine with me. Fixed.

It won't work, just like it doesn't work for gcc-toolchain. When you do

(without my patches):

guix build hello --with-c-toolchain=hello=clang-toolchain

--target=i686-unknown-linux-gnu

it builds, but that's because --with-c-toolchain replaces "gcc"

(and friends), but the cross package uses "cross-gcc".

guix build hello --with-c-toolchain=hello=gcc-toolchain@7

--target=i686-unknown-linux-gnu

also builds, but uses the latest gcc instead of gcc-toolchain@7.

Will send v2 shortly, after I've tested the rename works.

Julien Lepiller schreef op do 03-03-2022 om 19:35 [+0100]:

Search for 'cross-pkg-config' and 'standard-cross-packages'.

Greetings,

Maxime.

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

That's really cool! Out of curiosity, what target are you interested in

that clang supports and GCC doesn't? For instance I'm interested in

WebAssembly, and I've actually been contemplating how we could improve

support for cross-compilers based on Clang in Guix, to be able to

provide a working WebAssembly toolchain.

For context, such a toolchain will be needed to enable potential use of

WebAssembly in IceCat, for security purposes, see

I actually have a toolchain that works already, which targets the

wasm32-wasi-unknown triplet, but I wasn't convinced the way I did it was

the right way to go long term, so it needs more work. I'm attaching the

patch in case there's anything useful to you in there already!

The approach I took was to create wrappers around clang/clang++ in order

to set the correct include paths, and then provide an isolated sysroot

for wasm32-wasi using union-build. This will work for IceCat, where

their should be a flag to pass a sysroot path, but we should be able to

do better in Guix.

I though I'd share in case that's helpful! I'll take a look at your

patches to see if I can build on top of them for a future WebAssembly

toolchain in Guix.

Thanks,

Pierre

Le Thu, 03 Mar 2022 19:59:17 +0100,

Maxime Devos <maximedevos@telenet.be> a écrit :

Thanks! I used mlambda, I think it should work :)

So I tried renaming clang to <target>-clang, but then I noticed the

build of libcxxabi fails:

-- The CXX compiler identification is unknown

-- The C compiler identification is unknown

CMake Error at CMakeLists.txt:21 (project):

The CMAKE_CXX_COMPILER:

clang++

is not a full path and was not found in the PATH.

Tell CMake where to find the compiler by setting either the

environment variable "CXX" or the CMake cache entry

CMAKE_CXX_COMPILER to the full path to the compiler, or to the

compiler name if it is in the PATH.

This is because it really expects clang, not <target>-clang. The

autotools might be smarter (haven't tested), but they're the only one.

I don't want to substitute* every CMakeList.txt to make sure they

understand what we're the only ones to do.

Furthermore, clang is already a cross-compiler, and cross-clang only

makes it work in the context of guix packaging and changes the default

target for convenience. Outside of a guix package, although not very

convenient, our clang package already works like everyone else's I

think. I don't think it makes sense to have clang AND i586-gnu-clang in

your profile. Also, cross-clang just like cross-gcc is not accessible

from the CLI.

WDYT?

Oh wow!

I need clang for Android: it's only tested and built with clang, and some of the packages don't build with gcc. I don't really need any fancy target, but one of the goals I had was to be able to cross-build my android packages, hence this cross-compiler.

A wasm cross-compiler would be awesome!

On March 3, 2022 9:51:01 PM GMT+01:00, Pierre Langlois <pierre.langlois@gmx.com> wrote:

---

gnu/packages/llvm.scm | 21 +++++++++++++++++++--

1 file changed, 19 insertions(+), 2 deletions(-)

---

gnu/packages/llvm.scm | 144 +++++++++++++++++++++++++++++++++++++++++-

1 file changed, 143 insertions(+), 1 deletion(-)

[inputs]: ...here.

[arguments]: adjust CROSS_INCLUDE_PATH when cross-compiling.

(libcxx-6)[native-inputs]: Move llvm to...

[inputs]: ...here.

---

gnu/packages/llvm.scm | 23 +++++++++++++++--------

1 file changed, 15 insertions(+), 8 deletions(-)

clang-for-target for cross-compilation. Move llvm and libcxx to...

[inputs]: ...here.

[arguments]<adjust-CPLUS_INCLUDE_PATH>: Also adjust

CROSS_CPLUS_INCLUDE_PATH when necessary.

---

gnu/packages/llvm.scm | 40 ++++++++++++++++++++++++++++++++--------

1 file changed, 32 insertions(+), 8 deletions(-)

(libcxxabi-6): Inherit from it.

---

gnu/packages/llvm.scm | 69 ++++++++++++++++++++++++++++++++-----------

1 file changed, 51 insertions(+), 18 deletions(-)

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

Do you really need to define a cross package for LLVM? In my experience

it was possible to use the same llvm libraries for native and cross

compilation. By default LLVM builds support for all supported targets

(provided they are not "experimental" IIRC).

Whereas for the clang package, at the moment it does have to be built

for a specific target IIUC. I hope that one day we could have the same

clang for native and cross compilation in Guix, but I don't think it can

work without some serious re-design of how cross-compilation works. I've

been trying to think about it but I don't yet have a good understanding

of it.

Thanks,

Pierre

Julien Lepiller schreef op vr 04-03-2022 om 10:59 [+0100]:

Could the new procedure could 'clang-for-target' be used here?

Likewise for a few other packages (e.g. hedgewards), but those could be

left for future patches.

Greetings,

Maxime

Julien Lepiller schreef op vr 04-03-2022 om 10:59 [+0100]:

This is a bit fragile. If the definition of the 'clang' package mad

the #:configure-flags a gexp, then this would fail because of the

'sexp->gexp' optimisation in 'cmake-build-system'. As such, I

recommend #~(list "-DCLANG_INCLUDE_TESTS=True" ...) here instead of

sexp quasiquoting.

Greetings,

Maxime.

Julien Lepiller schreef op vr 04-03-2022 om 10:59 [+0100]:

Do we need something similar for non-x86-64 architectures as well?

Greetings,

Maxime.

Julien Lepiller schreef op vr 04-03-2022 om 10:59 [+0100]:

Shouldn't we use the architecture that the cross-clang is targetting be

passed to 'glibc-dynamic-linker' instead of the architecture that the

cross-clang will run on?

Greetings,

Maxime.

Julien Lepiller schreef op vr 04-03-2022 om 10:59 [+0100]:

Most of the time, we aren't cross-compiling. So WDYT of autoloading

this module? It's rather unusual to do this in (gnu packages ...), but

there does not appear to be any reason for this to be impossible to do.

Another option would be using 'module-ref' like (guix build-system ...)

does.

Greetings,

Maxime.

Julien Lepiller schreef op do 03-03-2022 om 19:35 [+0100]:

In that case, could this limitation be documented in

@deffn {Scheme Procedure} package-with-c-toolchain @var{package} @var{toolchain}

in the manual? Modifying (guix transformations) to also replace

the cross-toolchain would be even better.

Greetings,

Maxime

Le Fri, 04 Mar 2022 19:34:07 +0000,

Pierre Langlois <pierre.langlois@gmx.com> a écrit :

No, I don't think it's required. I only need it so I can define a

default target that's different from the host.

You can use --target to control which target clang builds for (although

I don't know if our clang package can work like that). I wanted to have

a default target though, because passing --target all the time is

cumbersome and we would have to adjust all recipes to pass the flag.

With the default target set appropriately, (clang-for-target) will

always produce binaries for the correct architecture, whether

cross-compiling or not.

Le Fri, 04 Mar 2022 20:54:22 +0100,

Maxime Devos <maximedevos@telenet.be> a écrit :

I don't know about that. This phase is mostly copied from clang itself.

Julien Lepiller <julien@lepiller.eu> writes:

Ah I see, that makes sense! I suppose a possible alternative could be

to define a wrapper around clang to pass the `--target=<triplet>' option

by default, but that might be a bit ugly (although we already have a

ld-wrapper).

Thanks,

Pierre

Julien Lepiller <julien@lepiller.eu> writes:

While playing with trying to use this series to build a WebAssembly

cross-compiler, I /think/ we have a bug here, and also in master, when

it comes to setting LLVM_TARGET_ARCH.

It's a bit confusing though, the documentation is as follows:

It's not clear what naming scheme the variable needs, is it the internal

LLVM target name or the triplet? I think it's architecture part of the

triplet...ish? But instead we pass it the internal target name.

It still works at the moment because whenever LLVM_TARGET_ARCH is used,

the cmake code looks quite permissive and tries to do the right thing by

turning the string lowercase and matching common names (hence the "...ish" :-) ).

So if I try and add WebAssembly into the mix, the architecure name is

wasm32, but the LLVM target is called WebAssembly, and the lowercase

version of it doesn't work :-(

| nix-system | LLVM target | LLVM target lowercase | Does it match? |

|------------+-------------+-----------------------+----------------|

| aarch64 | AArch64 | aarch64 | Y |

| armhf | ARM | arm | Y |

| mips64el | Mips | mips | Y |

| powerpc | PowerPC | powerpc | Y |

| riscv | RISCV | riscv | Y |

| x86_64 | X86 | x86 | Y |

| i686 | X86 | x86 | Y |

| i586 | X86 | x86 | Y |

|------------+-------------+-----------------------+----------------|

| wasm32 | WebAssembly | webassembly | N :-( |

I /think/ we might want to use the nix-system instead of the LLVM target

for LLVM_TARGET_ARCH:

But I'm not sure, it might not work for mips64el for example, so we

could need yet-another-mapping.

Given it works as it is today with the current set of supported targets,

we don't necessarily need to fix it now. I'll be happy to take a look

later when eventually adding support for the wasm32-wasi toolchain in

Guix.

Thanks,

Pierre

Hi,

A couple of comments from me while testing this trying to build a

cross-toolchain with llvm-13. Hope this is helpful!

Julien Lepiller <julien@lepiller.eu> writes:

Testing this with llvm-13, this substitution doesn't look quite right

and causes the build to fail, they might have removed braces between

versions:

Doing a blame points to this commit, which suggest it's changed with

LLVM 10 release I believe.

Quick question, compiler-rt here is the host's runtime right? Do we not

need to cross-compile it as well?

It's not always clear to me what is part of compiler-rt vs libc vs

libgcc, it could be target-dependent. For example when trying to target

WebAssembly, I needed a cross-compiled compiler-rt to provide the

libclang_rt.builtins-wasm32.a library.

Hello Julien and all,

Looks like quite a lot of work has gone into this patch series. What’s

the status? It would be nice to push it past the finish line!

TIA,

Ludo’.

So, I tried using only a wrapper around clang to pass --target.

However, this doesn't seem to be enough: the code disables LIBRARY_PATH

when cross-compiling and it picks up the wrong gcc:lib and libc

headers.

Instead, I tried to improve the previous patches, and here is v3. To

reply (maybe again) to remarks on the previous version:

- no it's not necessary to build a specific llvm package, but that way

we make sure that the default target is the one we want, so we don't

have to change the instructions for packages that use it, or to use a

wrapper to pass the --target argument. Maybe a wrapper could work

better though.

- clang-for-target was added in the patch that adds cross-clang.

- the configure flags are now a gexp

- I kept the substitute for "/lib64/ld-linux-x86-64.so.2", it's the

same instructions as in clang, so I prefer not to change it. It's a

bit sad that we'll have to change in both places if needed :/

- (gnu packages cross-base) is autoloaded now

- I'll leave documenting limitations of package-with-c-toolchain (or

improving it) to another time.

- I have no idea how to make it work for wasm, but that can probably be

fixed another time. Also, it's not listed in supported targets, and

guix doesn't let me build for that target anymore.

- Fixed build issues for clang >=10.

I also agree that clang-runtime should be cross-compiled. It is a

propagated-input, but cross-clang is a native package that is a

cross-compiler for another architecture, so the inputs are native too.

Since I couldn't figure out how to make a package for a given target, I

added a transformation to (guix build-system) that replaces the

keywords to force a package to build for a given architecture.

Also, I added libcxx and libcxxabi 12 at the end because I need them

for the newer versions of android tools.

---

guix/build-system.scm | 21 ++++++++++++++++++++-

1 file changed, 20 insertions(+), 1 deletion(-)

CROSS_CPLUS_INCLUDE_PATH in the same way as CPLUS_INCLUDE_PATH.

---

gnu/packages/llvm.scm | 17 +++++++++++++++--

1 file changed, 15 insertions(+), 2 deletions(-)

`(package-arguments llvm-10)' evaluates `this-package' in the context of

llvm-10. `llvm-tblgen' in llvm-10 is not compatible with llvm-9, so

copy the configure-flags from llvm-12 to make sure `this-package' is

evaluated here.

---

gnu/packages/llvm.scm | 25 ++++++++++++++++++++++++-

1 file changed, 24 insertions(+), 1 deletion(-)

---

gnu/packages/llvm.scm | 21 +++++++++++++++++++--

1 file changed, 19 insertions(+), 2 deletions(-)

---

gnu/packages/llvm.scm | 169 +++++++++++++++++++++++++++++++++++++++++-

1 file changed, 168 insertions(+), 1 deletion(-)

[inputs]: ...here.

[arguments]: adjust CROSS_INCLUDE_PATH when cross-compiling.

(libcxx-6)[native-inputs]: Move llvm to...

[inputs]: ...here.

---

gnu/packages/llvm.scm | 23 +++++++++++++++--------

1 file changed, 15 insertions(+), 8 deletions(-)

clang-for-target for cross-compilation. Move llvm and libcxx to...

[inputs]: ...here.

[arguments]<adjust-CPLUS_INCLUDE_PATH>: Also adjust

CROSS_CPLUS_INCLUDE_PATH when necessary.

---

gnu/packages/llvm.scm | 40 ++++++++++++++++++++++++++++++++--------

1 file changed, 32 insertions(+), 8 deletions(-)

(libcxxabi-6): Inherit from it.

---

gnu/packages/llvm.scm | 66 +++++++++++++++++++++++++++++++------------

1 file changed, 48 insertions(+), 18 deletions(-)

(libcxx-9): ...this.

(libcxx-12): New variable.

---

gnu/packages/llvm.scm | 38 ++++++++++++++++++++++++++++++--------

1 file changed, 30 insertions(+), 8 deletions(-)

(libcxxabi-9): Inherit from it.

---

gnu/packages/llvm.scm | 53 +++++++++++++++++++++++++++++++++----------

1 file changed, 41 insertions(+), 12 deletions(-)

On 16-07-2022 21:44, Julien Lepiller wrote:

Try:

scheme@(guix-user)> ,build (with-parameters ((%current-target-system

"aarch64-linux-gnu")) (specification->package "hello"))

[...]

$3 = "/gnu/store/rys78r4j72zh45xchq87x2y30ya8mzvi-hello-2.12.1"

Greetings,

Maxime.

Le Tue, 19 Jul 2022 21:54:16 +0200,

Maxime Devos <maximedevos@telenet.be> a écrit :

Thanks, that was a lot easier than I thought. So I removed the first

patch and changed to (with-parameters ((%current-target-system target))

base) in cross-clang.