Subject: Re: [bug#54239] [PATCH] gnu: Add cross-clang.

From: Julien Lepiller <[email-masked]>
Date: Thu, 3 Mar 2022 19:35:03 +0100

Le Thu, 03 Mar 2022 17:40:36 +0100,
Maxime Devos <[email-masked]> a écrit :

> Julien Lepiller schreef op do 03-03-2022 om 17:02 [+0100]:
> > 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  
> 
> Do you mean (%current-target-system)?

yes, that's what I meant.

> 
> 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)?

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

> 
> >      (native-inputs
> > -     (list clang llvm))
> > +     (list (if (%current-target-system)
> > +               (cross-clang (%current-target-system) #:clang
> > clang-9)
> > +               clang-9)))  
> 
> 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 ...))

Great idea, I implemented that procedure.

> 
> 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?

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.

> > + ;; Support the same variables as clang, even in cross-compilation
> > + ;; context.
> > + ;; Clang does not make a difference between native and
> > + ;; cross-compilation.  
> 
> 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.
> 

OK, fixed.

> > +           (files '("lib" "lib64"))))  
> 
> 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).

I saw that in GCC, so I just used the same specification, but just
'("lib") is fine with me. Fixed.

> 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?

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.

> Greetings,
> Maxime.