[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#54239] [PATCH] gnu: Add cross-clang.
From: |
Julien Lepiller |
Subject: |
[bug#54239] [PATCH] gnu: Add cross-clang. |
Date: |
Thu, 3 Mar 2022 19:35:03 +0100 |
Le Thu, 03 Mar 2022 17:40:36 +0100,
Maxime Devos <maximedevos@telenet.be> 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.