• Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR va

    From James Beddek@21:1/5 to All on Thu Dec 16 10:36:44 2021
    On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values.

    Doing this avoids situations like building the kernel with
    clang (using the set HOSTCC) but using gcc/gnu-ar for headers.

    [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

    Co-authored-by: Manoj Gupta <manojgupta@chromium.org>
    Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
    ---
    eclass/kernel-2.eclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
    index adc1425bc2e..caeec86ff59 100644
    --- a/eclass/kernel-2.eclass
    +++ b/eclass/kernel-2.eclass
    @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
    elif type -p ${CHOST}-ar >/dev/null; then
    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
    fi
    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
    + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC) AR=$(tc-getAR)" export xmakeopts
    }

    What's the reason for not using $LLVM here? To preserve building with clang
    for kernels < 5.7 ?

    I might be missing the point, but wouldn't something along the lines of "LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to preserve the correct compiler tools?

    Cheers
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE6TiHvKPfjLbCYrJRC091Pag9upAFAmG6X+wACgkQC091Pag9 upCQXg//R/+WDd6mhjOW+KJVuP/L4JOEUt2qmxbW5kAL8+mOjCPJwBMYJjOietWY a4hKWNIAf031N+ybmG+rwtT9Bfgsa5AK4hQxbg25IJbWzkKtMY/Bx+fVKr5JV9KH AUdSOfU7rZDHlIzK+mlrjMNDr8851Em+VafpRRw4zrwZ841aLkJ8dqso6PuYfsda vE/n7su6XfcXcR7ItmGPinjM17RJUZwu2ODLdGNuLKNYxIHt+qHJZnq1YrtkZ40U c7UZCIZtQU/Exc8A3KVon5t+kfBEr9DSvx8wMsv8t+mSK9XsEs6RogQgkUnape4n kCf//q3vT4XspXLwi/k++J10LfFCt0v/VIfzCakd25evspNQmwfJfqOjN8BIUhPT em5NQ8wTHbvmf8DPyXo7ZoGL6JR5Mt14BwzEn0GNozW/4HiBYTsXwe1cK7dMzYdC GV6gEqz6J9gqJxMptpRIGYQsIsrRuvZnsTltd4A1AkIlxE7B+YTQIUo+MFE3OnpM k5jS9VqDh5zYHur1ldNLClLq7V4gUefFw2RS0472zK+a/vS2kIo1OVEZkB7d83w3 CA2xYv3atSPUjhaIfONNxffB4QnjsM9XOFl/PyZcPLJxdCz18OGm+yOwzsQREE6V kqhcn03pec6Aua5Bi6O+FGcr4cLnr5PumIZDqsCBa8H+OAeoBOY=
    =7u0j
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manoj Gupta@21:1/5 to telans@posteo.de on Wed Dec 15 22:50:01 2021
    On Wed, Dec 15, 2021 at 1:37 PM James Beddek <telans@posteo.de> wrote:

    On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values.

    Doing this avoids situations like building the kernel with
    clang (using the set HOSTCC) but using gcc/gnu-ar for headers.

    [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

    Co-authored-by: Manoj Gupta <manojgupta@chromium.org>
    Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
    ---
    eclass/kernel-2.eclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
    index adc1425bc2e..caeec86ff59 100644
    --- a/eclass/kernel-2.eclass
    +++ b/eclass/kernel-2.eclass
    @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
    elif type -p ${CHOST}-ar >/dev/null; then
    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
    fi
    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
    + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC) AR=$(tc-getAR)" export xmakeopts
    }

    What's the reason for not using $LLVM here? To preserve building with
    clang
    for kernels < 5.7 ?

    I might be missing the point, but wouldn't something along the lines of "LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to preserve the
    correct
    compiler tools?

    This patch is about respecting the current CC value in portage. It could
    be clang, icc, or something else
    What should be the value of CC should be up to the user's portage config.

    In Chrome OS e.g., we have multiple possible CC's with variants like <abi>-clang. So hardcoding clang
    also does not look correct.

    Thanks,
    Manoj


    Cheers

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 15, 2021 at 1:37 PM James Beddek &lt;<a href="mailto:telans@posteo.de">telans@posteo.de</a>&gt; wrote:<br></div><blockquote class="gmail_
    quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu wrote:<br>
    &gt; Starting with kernel&gt;=v5.7 the build system can override the<br>
    &gt; tools vars by setting LLVM=1 [1], but older kernels still use<br>
    &gt; the default GNU tools, so to be able to use a full LLVM/Clang<br>
    &gt; build, CC should be set together with AR to the portage set<br>
    &gt; values.<br>
    &gt; <br>
    &gt; Doing this avoids situations like building the kernel with<br>
    &gt; clang (using the set HOSTCC) but using gcc/gnu-ar for headers.<br>
    &gt; <br>
    &gt; [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to<br> &gt; Clang/LLVM<br>
    &gt; <br>
    &gt; Co-authored-by: Manoj Gupta &lt;<a href="mailto:manojgupta@chromium.org" target="_blank">manojgupta@chromium.org</a>&gt;<br>
    &gt; Signed-off-by: Adrian Ratiu &lt;<a href="mailto:adrian.ratiu@collabora.com" target="_blank">adrian.ratiu@collabora.com</a>&gt;<br>
    &gt; ---<br>
    &gt;  eclass/kernel-2.eclass | 2 +-<br>
    &gt;  1 file changed, 1 insertion(+), 1 deletion(-)<br>
    &gt; <br>
    &gt; diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass<br>
    &gt; index adc1425bc2e..caeec86ff59 100644<br>
    &gt; --- a/eclass/kernel-2.eclass<br>
    &gt; +++ b/eclass/kernel-2.eclass<br>
    &gt; @@ -692,7 +692,7 @@ env_setup_xmakeopts() {<br>
    &gt;       elif type -p ${CHOST}-ar &gt;/dev/null; then<br>
    &gt;               xmakeopts=&quot;${xmakeopts} CROSS_COMPILE=${CHOST}-&quot;<br>
    &gt;       fi<br>
    &gt; -     xmakeopts=&quot;${xmakeopts} HOSTCC=$(tc-getBUILD_CC)&quot;<br> &gt; +     xmakeopts=&quot;${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)<br>
    &gt; AR=$(tc-getAR)&quot; export xmakeopts<br>
    &gt;  }<br>

    What&#39;s the reason for not using $LLVM here? To preserve building with clang <br>
    for kernels &lt; 5.7 ?<br>

    I might be missing the point, but wouldn&#39;t something along the lines of<br> &quot;LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)&quot; work to preserve the correct <br>
    compiler tools?<br>
    <br></blockquote><div>This patch is about respecting the current CC value in portage. It could be clang, icc, or something else</div><div>What should be the value of CC should be up to the user&#39;s portage config.</div><div><br></div><div>In Chrome OS
    e.g., we have multiple possible CC&#39;s with variants like &lt;abi&gt;-clang. So hardcoding clang</div><div>also does not look correct.</div><div><br></div><div>Thanks,</div><div>Manoj</div><div>  </div><blockquote class="gmail_quote" style="margin:
    0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Cheers</blockquote></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrew Savchenko@21:1/5 to All on Thu Dec 16 01:40:02 2021
    On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
    On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values.

    Doing this avoids situations like building the kernel with
    clang (using the set HOSTCC) but using gcc/gnu-ar for headers.

    [1] a0d1c951ef08 kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

    Co-authored-by: Manoj Gupta <manojgupta@chromium.org>
    Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
    ---
    eclass/kernel-2.eclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
    index adc1425bc2e..caeec86ff59 100644
    --- a/eclass/kernel-2.eclass
    +++ b/eclass/kernel-2.eclass
    @@ -692,7 +692,7 @@ env_setup_xmakeopts() {
    elif type -p ${CHOST}-ar >/dev/null; then
    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
    fi
    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)"
    + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC) AR=$(tc-getAR)"

    OBJDUMP should be exported as well
    (e.g. used by scripts/Makefile.build)

    And LD as well.

    export xmakeopts
    }



    Best regards,
    Andrew Savchenko


    Best regards,
    Andrew Savchenko

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAmG6ilYACgkQ9lNaM7oe 5I0I5w/9Hd1qfzkrnIAbVDa+cjmmIGDPa6ovHwe/yemJkDLh9dcc9R7HbYlhhCFQ Cxu2/TH7l7YjCXbJb0DArH7oZynuGcZumot9UfkNvit1b00KEY297FzVWWaQBHqA hPJrv15y4ZyE533B/qaW5hN2Aa2Vmm3ouyulP+IyW+iS67rtbCQebDLNbtu+4OkA GHjvTZEa3jC4EyPNkkuO1tl909N9WzwbFxnb4pLe4AYC64sgXziVrCtwLWMCj/ow 8U8ZnxAwO04GViMNW+bxsSxXmAQ6PP13hPOO7prXgGocGXgRcg4wyrIg93UEdIIG REGKKo7cg07kEELgZBXgnldtTBdcc/f130PLFSOZ3dNtR4tAkEro3LmjhFZ0WHLA +uKFwfUwbvvEChu7bMqoNMBJB2XwTyCcieiMBV88owY1MTlcSWDiRYhdU8R/vPBD diHHa2HkWkOj2Li6NhjSTzoz88P4d3uL6hoWSshTIR12WUlgyItaOTTH9hf3VDwW 1+cAA30lYDA0q2HmhpBIQ7j7kqH8UEyBnLmMjd1CNNjoHhbTp4TTbQ8Vuo4YEEXM C3ZGWjV3eflBhtLTivscAwzZws6++cn1XuyVB4+CQib9SvueNZ45UM5xifiC8VlO WaLsuav9ZcxnHvKj3DeKtGDJk5ucaqHJZ6Abn7HNMIEexy1X0kE=
    =s2Eo
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adrian Ratiu@21:1/5 to Andrew Savchenko on Thu Dec 16 20:40:03 2021
    Hi Andrew,

    On Thu, 16 Dec 2021, Andrew Savchenko <bircoph@gentoo.org> wrote:
    On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
    On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values. Doing this avoids situations like building the
    kernel with clang (using the set HOSTCC) but using gcc/gnu-ar
    for headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to
    switch the default tools to Clang/LLVM Co-authored-by: Manoj
    Gupta <manojgupta@chromium.org> Signed-off-by: Adrian Ratiu
    <adrian.ratiu@collabora.com> ---
    eclass/kernel-2.eclass | 2 +- 1 file changed, 1
    insertion(+), 1 deletion(-)
    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
    index adc1425bc2e..caeec86ff59 100644 ---
    a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@
    -692,7 +692,7 @@ env_setup_xmakeopts() {
    elif type -p ${CHOST}-ar >/dev/null; then
    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi
    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
    xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)
    CC=$(tc-getCC) AR=$(tc-getAR)"
    OBJDUMP should be exported as well (e.g. used by
    scripts/Makefile.build)

    And LD as well.


    Thank you very much for the suggestions!

    I only set CC and AR because there were the two which failed in my
    testing, but yes, it is a good idea to be prudent and set them all
    if nobody is oopposed to it.

    I will leave this patch on the ML a bit in case there is more
    feedback (it is also EoY season so people might be busy), then I
    will send a v3 with the new variables included.

    Thanks again,
    Adrian

    export xmakeopts
    }



    Best regards,
    Andrew Savchenko


    Best regards,
    Andrew Savchenko

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adrian Ratiu@21:1/5 to James Beddek on Thu Dec 16 20:40:02 2021
    Hi James, thank you very much for your feedback!

    On Wed, 15 Dec 2021, James Beddek <telans@posteo.de> wrote:
    On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu
    wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values. Doing this avoids situations like building the kernel
    with clang (using the set HOSTCC) but using gcc/gnu-ar for
    headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to switch
    the default tools to Clang/LLVM Co-authored-by: Manoj Gupta
    <manojgupta@chromium.org> Signed-off-by: Adrian Ratiu
    <adrian.ratiu@collabora.com> ---
    eclass/kernel-2.eclass | 2 +- 1 file changed, 1 insertion(+),
    1 deletion(-)
    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
    index adc1425bc2e..caeec86ff59 100644 ---
    a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@ -692,7
    +692,7 @@ env_setup_xmakeopts() {
    elif type -p ${CHOST}-ar >/dev/null; then
    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi
    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
    xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
    AR=$(tc-getAR)" export xmakeopts
    }

    What's the reason for not using $LLVM here? To preserve building
    with clang for kernels < 5.7 ?

    That is correct - if Gentoo were to support only kernels >= 5.7
    then we could try to use $LLVM directly, but older long-term
    releases are still supported, the upstream kernel will backport
    patches to v4.14 until Jan 2024 and we would really like to build
    these with Clang too.


    I might be missing the point, but wouldn't something along the
    lines of "LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to
    preserve the correct compiler tools?

    In theory Manoj's argument is correct: this is about respecting CC
    and the tools configuration in general so we should try to avoid
    hardcoding for clang if possible, but...

    In practice I'm not aware of people building the kernel with
    something other than GNU or LLVM variants. At least these are the
    only two which receive "first class" support by the upstream
    kernel community.

    In addition, hardcoding $LLVM does not fix the problem of older
    kernels.

    I thought about backporting $LLVM support to long-term releases
    but I don't think it would be acceptable for inclusion in older
    kernels which should receive only bug fixes.

    This is why I think the best solution is to just set the variables
    in this eclass to the values set by portage.

    Thanks,
    Adrian


    Cheers

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Beddek@21:1/5 to All on Fri Dec 17 12:13:13 2021
    On Friday, 17 December 2021 8:29:18 AM NZDT Adrian Ratiu wrote:
    Hi Andrew,

    On Thu, 16 Dec 2021, Andrew Savchenko <bircoph@gentoo.org> wrote:
    On Thu, 16 Dec 2021 03:32:10 +0300 Andrew Savchenko wrote:
    On Wed, 15 Dec 2021 16:58:26 +0200 Adrian Ratiu wrote:
    Starting with kernel>=v5.7 the build system can override the
    tools vars by setting LLVM=1 [1], but older kernels still use
    the default GNU tools, so to be able to use a full LLVM/Clang
    build, CC should be set together with AR to the portage set
    values. Doing this avoids situations like building the
    kernel with clang (using the set HOSTCC) but using gcc/gnu-ar
    for headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to
    switch the default tools to Clang/LLVM Co-authored-by: Manoj
    Gupta <manojgupta@chromium.org> Signed-off-by: Adrian Ratiu
    <adrian.ratiu@collabora.com> ---

    eclass/kernel-2.eclass | 2 +- 1 file changed, 1
    insertion(+), 1 deletion(-)
    diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass

    index adc1425bc2e..caeec86ff59 100644 ---
    a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@
    -692,7 +692,7 @@ env_setup_xmakeopts() {

    elif type -p ${CHOST}-ar >/dev/null; then

    xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi

    - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
    xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)
    CC=$(tc-getCC) AR=$(tc-getAR)"

    OBJDUMP should be exported as well (e.g. used by

    scripts/Makefile.build)

    And LD as well.

    Thank you very much for the suggestions!

    I only set CC and AR because there were the two which failed in my
    testing, but yes, it is a good idea to be prudent and set them all
    if nobody is oopposed to it.


    I assume by set them all you're referring to what the kernel makefile uses? I think CC, LD, AR, NM, OBJCOPY, OBJDUMP, READELF, and STRIP is the exhaustive list for the kernel. (would match the new clang profile feature too)

    Thanks

    I will leave this patch on the ML a bit in case there is more
    feedback (it is also EoY season so people might be busy), then I
    will send a v3 with the new variables included.

    Thanks again,
    Adrian

    export xmakeopts

    }

    Best regards,
    Andrew Savchenko

    Best regards,
    Andrew Savchenko


    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEE6TiHvKPfjLbCYrJRC091Pag9upAFAmG7yAkACgkQC091Pag9 upDfNRAAt+IwyidM9yupeMO2t/tZqs/JouymMHcKJrmdRGl9cck8LGitUGoBhbr7 nPvYc4IJPES67bQ1NpGac61a1CVF24zXm+I2XKvu/T41j1TFZZxmmZF1Voa2r+bC jvYeRNd+2hkMrYNsq3ikhegONZPQkj48l6BkJBu6tBnFxo3cHUp21jewAx/9S7pJ CO4cpqo2tiRQD0EVcqFG/nFMS/vyrsSN6Gc0meni/38jcGfQgksY7jtJWosOd5tS pg/ZoGMxXMQS1iTwzwN+WMrcR6JfyD1+xEf7Yj+g9pc0C/Ue9O3VmhB5OKtL/i4q OTpr7yk/ySVUcK7ParO/UmPDgif/S8MTzjpinqVrUr1UlWkzyqTXgUaDxKFSLgzT KifBllz82ifSCJIgjBKFKanX6PnEQuDaAUWAewuW6ljEMRFw51gkMxxW4pYCGzmS 5/+ypRfwRdefjxT32SHi0ZZNCoxc3gZ8cEGtfaagLD/sLLBh1UcIq802JbYEkQBj 0ima5malnvSgfj4qxGTCWRYdAOPPSc9XDmMfj43eQgKOKXinYd4zGmvdWviWoNe3 v2Fx8hITD6wxERp3t3p25kTUr9jHWyfwkAcC27ontgEGjMek54sfQUnEFDQcc216 7QNlTBK9V0uzHysfiWz/mkRkYZn57riW/4wlLUfPfh8pgFXhjnY=
    =OkLX
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)