[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Yann E. MORIN]

Some packages that use libtool really need some love to be able to
disable C++ support.

This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
will want a C++ preprocessor that works on valid input *and* fail on
invalid input.

So, providing 'false' as the C++ compiler will then require that we do
have a working C++ preprocessor. Which is totally counter-productive
since we do not have a C++ compiler to start with...

bd39d11d2e (core/infra: fix build on toolchain without C++) was a
previous attempt at fixing this, by using the host's C++ preprocessor.

However, that is very incorrect (that's my code, I can say so!) because
the set of defines will most probably be different for the host and the
target, thus causign all sorts of trouble. For example, on ARM we'd have
to include different headers for soft-float vs hard-float, which is
decided based on a macro, which is not defined for x86, and thus may
redirect to the wrong (and missing) header.

Instead, we notice that libtool uses the magic value 'no' to decide that
a C++ compiler is not available, in which case it skeips the call to
AC_PROG_CXXCPP.

Given that 'no' is not provided by any package in Debian and
derivatives, as well as in Fedora, we can assume that no system will
have an executable called 'no'. Hence, we use that as a magic value to
disable C++ detection altogether.

Fixes: #10846 (again)

Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

---
Changes v1 -> v2:
  - add big fat comment...

---
 package/Makefile.in | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/package/Makefile.in b/package/Makefile.in
index e387ce67fe..57fb47ea2e 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -409,8 +409,16 @@ else
 NLS_OPTS = --disable-nls
 endif
 
+# We need anything that is invalid. Traditionally, we'd have used 'false' (and
+# we did so in the past). However, that breaks libtool for packages that have
+# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
+# C++ preprocessor as long as CXX is not 'no'.
+# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
+# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
+# expected and what we want), while at the same time taming libtool into
+# silence.
 ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
-TARGET_CONFIGURE_OPTS += CXX=false CXXCPP=cpp
+TARGET_CONFIGURE_OPTS += CXX=no
 endif
 
 ifeq ($(BR2_STATIC_LIBS),y)
-- 
2.14.1

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Baruch Siach]

Hi Yann,

On Tue, Mar 27, 2018 at 01:00:22PM +0200, Yann E. MORIN wrote:
> Some packages that use libtool really need some love to be able to
> disable C++ support.
> 
> This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
> is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
> will want a C++ preprocessor that works on valid input *and* fail on
> invalid input.
> 
> So, providing 'false' as the C++ compiler will then require that we do
> have a working C++ preprocessor. Which is totally counter-productive
> since we do not have a C++ compiler to start with...
> 
> bd39d11d2e (core/infra: fix build on toolchain without C++) was a
> previous attempt at fixing this, by using the host's C++ preprocessor.
> 
> However, that is very incorrect (that's my code, I can say so!) because
> the set of defines will most probably be different for the host and the
> target, thus causign all sorts of trouble. For example, on ARM we'd have
> to include different headers for soft-float vs hard-float, which is
> decided based on a macro, which is not defined for x86, and thus may
> redirect to the wrong (and missing) header.
> 
> Instead, we notice that libtool uses the magic value 'no' to decide that
> a C++ compiler is not available, in which case it skeips the call to
> AC_PROG_CXXCPP.
> 
> Given that 'no' is not provided by any package in Debian and
> derivatives, as well as in Fedora, we can assume that no system will
> have an executable called 'no'. Hence, we use that as a magic value to
> disable C++ detection altogether.
> 
> Fixes: #10846 (again)
> 
> Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Cc: Peter Seiderer <ps.report@gmx.net>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Cc: Peter Korsgaard <peter@korsgaard.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> 
> ---
> Changes v1 -> v2:
>   - add big fat comment...
> 
> ---
>  package/Makefile.in | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/package/Makefile.in b/package/Makefile.in
> index e387ce67fe..57fb47ea2e 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -409,8 +409,16 @@ else
>  NLS_OPTS = --disable-nls
>  endif
>  
> +# We need anything that is invalid. Traditionally, we'd have used 'false' (and
> +# we did so in the past). However, that breaks libtool for packages that have
> +# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
> +# C++ preprocessor as long as CXX is not 'no'.
> +# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
> +# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
> +# expected and what we want), while at the same time taming libtool into
> +# silence.
>  ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
> -TARGET_CONFIGURE_OPTS += CXX=false CXXCPP=cpp
> +TARGET_CONFIGURE_OPTS += CXX=no

What about CXXCPP? Your v1 patch set it to 'no'.

>  endif
>  
>  ifeq ($(BR2_STATIC_LIBS),y)

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Thomas Petazzoni]

Hello,

On Tue, 27 Mar 2018 15:04:32 +0300, Baruch Siach wrote:
> Hi Yann,
> 
> On Tue, Mar 27, 2018 at 01:00:22PM +0200, Yann E. MORIN wrote:
> > Some packages that use libtool really need some love to be able to
> > disable C++ support.
> > 
> > This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
> > is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
> > will want a C++ preprocessor that works on valid input *and* fail on
> > invalid input.
> > 
> > So, providing 'false' as the C++ compiler will then require that we do
> > have a working C++ preprocessor. Which is totally counter-productive
> > since we do not have a C++ compiler to start with...
> > 
> > bd39d11d2e (core/infra: fix build on toolchain without C++) was a
> > previous attempt at fixing this, by using the host's C++ preprocessor.
> > 
> > However, that is very incorrect (that's my code, I can say so!) because
> > the set of defines will most probably be different for the host and the
> > target, thus causign all sorts of trouble. For example, on ARM we'd have
> > to include different headers for soft-float vs hard-float, which is
> > decided based on a macro, which is not defined for x86, and thus may
> > redirect to the wrong (and missing) header.
> > 
> > Instead, we notice that libtool uses the magic value 'no' to decide that
> > a C++ compiler is not available, in which case it skeips the call to

skeips -> skips


> > +# We need anything that is invalid. Traditionally, we'd have used 'false' (and
> > +# we did so in the past). However, that breaks libtool for packages that have
> > +# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
> > +# C++ preprocessor as long as CXX is not 'no'.
> > +# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
> > +# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
> > +# expected and what we want), while at the same time taming libtool into
> > +# silence.
> >  ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
> > -TARGET_CONFIGURE_OPTS += CXX=false CXXCPP=cpp
> > +TARGET_CONFIGURE_OPTS += CXX=no  
> 
> What about CXXCPP? Your v1 patch set it to 'no'.

I think Yann's commit log explains it: if you specify CXX=no, then
libtool will not try to search for a C++ pre-processor, hence it is no
longer necessary to pass CXXCPP. At least that's my understanding of
Yann's commit log.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Yann E. MORIN]

Thomas, Baruch,

On 2018-03-27 14:43 +0200, Thomas Petazzoni spake thusly:
> On Tue, 27 Mar 2018 15:04:32 +0300, Baruch Siach wrote:
> > On Tue, Mar 27, 2018 at 01:00:22PM +0200, Yann E. MORIN wrote:
> > > Some packages that use libtool really need some love to be able to
> > > disable C++ support.
> > > 
> > > This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
> > > is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
> > > will want a C++ preprocessor that works on valid input *and* fail on
> > > invalid input.
> > > 
> > > So, providing 'false' as the C++ compiler will then require that we do
> > > have a working C++ preprocessor. Which is totally counter-productive
> > > since we do not have a C++ compiler to start with...
> > > 
> > > bd39d11d2e (core/infra: fix build on toolchain without C++) was a
> > > previous attempt at fixing this, by using the host's C++ preprocessor.
> > > 
> > > However, that is very incorrect (that's my code, I can say so!) because
> > > the set of defines will most probably be different for the host and the
> > > target, thus causign all sorts of trouble. For example, on ARM we'd have

s/causign/causing/

> > > to include different headers for soft-float vs hard-float, which is
> > > decided based on a macro, which is not defined for x86, and thus may
> > > redirect to the wrong (and missing) header.
> > > 
> > > Instead, we notice that libtool uses the magic value 'no' to decide that
> > > a C++ compiler is not available, in which case it skeips the call to
> skeips -> skips

ACK.

> > > +# We need anything that is invalid. Traditionally, we'd have used 'false' (and
> > > +# we did so in the past). However, that breaks libtool for packages that have
> > > +# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
> > > +# C++ preprocessor as long as CXX is not 'no'.
> > > +# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
> > > +# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
> > > +# expected and what we want), while at the same time taming libtool into
> > > +# silence.
> > >  ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
> > > -TARGET_CONFIGURE_OPTS += CXX=false CXXCPP=cpp
> > > +TARGET_CONFIGURE_OPTS += CXX=no  
> > 
> > What about CXXCPP? Your v1 patch set it to 'no'.
> 
> I think Yann's commit log explains it: if you specify CXX=no, then
> libtool will not try to search for a C++ pre-processor, hence it is no
> longer necessary to pass CXXCPP. At least that's my understanding of
> Yann's commit log.

Exactly. I can enhance the commit log to explain it further if you want.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Peter Seiderer]

Hello Yann,

On Tue, 27 Mar 2018 13:00:22 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Some packages that use libtool really need some love to be able to
> disable C++ support.
> 
> This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
> is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
> will want a C++ preprocessor that works on valid input *and* fail on
> invalid input.
> 
> So, providing 'false' as the C++ compiler will then require that we do
> have a working C++ preprocessor. Which is totally counter-productive
> since we do not have a C++ compiler to start with...
> 
> bd39d11d2e (core/infra: fix build on toolchain without C++) was a
> previous attempt at fixing this, by using the host's C++ preprocessor.
> 
> However, that is very incorrect (that's my code, I can say so!) because
> the set of defines will most probably be different for the host and the
> target, thus causign all sorts of trouble. For example, on ARM we'd have
> to include different headers for soft-float vs hard-float, which is
> decided based on a macro, which is not defined for x86, and thus may
> redirect to the wrong (and missing) header.
> 
> Instead, we notice that libtool uses the magic value 'no' to decide that
> a C++ compiler is not available, in which case it skeips the call to
> AC_PROG_CXXCPP.
> 
> Given that 'no' is not provided by any package in Debian and
> derivatives, as well as in Fedora, we can assume that no system will
> have an executable called 'no'. Hence, we use that as a magic value to
> disable C++ detection altogether.
> 
> Fixes: #10846 (again)

Fixes the gnutls configure failure described in Bug-10846...

Tested-by: Peter Seiderer <ps.report@gmx.net>

Regards,
Peter

> 
> Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Cc: Peter Seiderer <ps.report@gmx.net>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Cc: Peter Korsgaard <peter@korsgaard.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> 
> ---
> Changes v1 -> v2:
>   - add big fat comment...
> 
> ---
>  package/Makefile.in | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/package/Makefile.in b/package/Makefile.in
> index e387ce67fe..57fb47ea2e 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -409,8 +409,16 @@ else
>  NLS_OPTS = --disable-nls
>  endif
>  
> +# We need anything that is invalid. Traditionally, we'd have used 'false' (and
> +# we did so in the past). However, that breaks libtool for packages that have
> +# optional C++ support (e.g. gnutls), because libtool will *require* a *valid*
> +# C++ preprocessor as long as CXX is not 'no'.
> +# Now, whether we use 'no' or 'false' for CXX as the same side effect: it is an
> +# invalid C++ compiler, and thus will cause detection of C++ to fail (which is
> +# expected and what we want), while at the same time taming libtool into
> +# silence.
>  ifneq ($(BR2_INSTALL_LIBSTDCPP),y)
> -TARGET_CONFIGURE_OPTS += CXX=false CXXCPP=cpp
> +TARGET_CONFIGURE_OPTS += CXX=no
>  endif
>  
>  ifeq ($(BR2_STATIC_LIBS),y)

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Arnout Vandecappelle]

On 27-03-18 21:40, Peter Seiderer wrote:
> Hello Yann,
> 
> On Tue, 27 Mar 2018 13:00:22 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> 
>> Some packages that use libtool really need some love to be able to
>> disable C++ support.
>>
>> This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
>> is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
>> will want a C++ preprocessor that works on valid input *and* fail on
>> invalid input.
>>
>> So, providing 'false' as the C++ compiler will then require that we do
>> have a working C++ preprocessor. Which is totally counter-productive
>> since we do not have a C++ compiler to start with...
>>
>> bd39d11d2e (core/infra: fix build on toolchain without C++) was a
>> previous attempt at fixing this, by using the host's C++ preprocessor.
>>
>> However, that is very incorrect (that's my code, I can say so!) because
>> the set of defines will most probably be different for the host and the
>> target, thus causign all sorts of trouble. For example, on ARM we'd have
>> to include different headers for soft-float vs hard-float, which is
>> decided based on a macro, which is not defined for x86, and thus may
>> redirect to the wrong (and missing) header.
>>
>> Instead, we notice that libtool uses the magic value 'no' to decide that
>> a C++ compiler is not available, in which case it skeips the call to
>> AC_PROG_CXXCPP.
>>
>> Given that 'no' is not provided by any package in Debian and
>> derivatives, as well as in Fedora, we can assume that no system will
>> have an executable called 'no'. Hence, we use that as a magic value to
>> disable C++ detection altogether.
>>
>> Fixes: #10846 (again)
> 
> Fixes the gnutls configure failure described in Bug-10846...
> 
> Tested-by: Peter Seiderer <ps.report@gmx.net>

 Does that also imply that your earlier patch [1] can be marked as Superseded?

 Regards,
 Arnout

[1] http://patchwork.ozlabs.org/patch/889057/

> 
> Regards,
> Peter
[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Peter Seiderer]

On Thu, 29 Mar 2018 00:08:08 +0200, Arnout Vandecappelle <arnout@mind.be> wrote:

> On 27-03-18 21:40, Peter Seiderer wrote:
> > Hello Yann,
> > 
> > On Tue, 27 Mar 2018 13:00:22 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> >   
> >> Some packages that use libtool really need some love to be able to
> >> disable C++ support.
> >>
> >> This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
> >> is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
> >> will want a C++ preprocessor that works on valid input *and* fail on
> >> invalid input.
> >>
> >> So, providing 'false' as the C++ compiler will then require that we do
> >> have a working C++ preprocessor. Which is totally counter-productive
> >> since we do not have a C++ compiler to start with...
> >>
> >> bd39d11d2e (core/infra: fix build on toolchain without C++) was a
> >> previous attempt at fixing this, by using the host's C++ preprocessor.
> >>
> >> However, that is very incorrect (that's my code, I can say so!) because
> >> the set of defines will most probably be different for the host and the
> >> target, thus causign all sorts of trouble. For example, on ARM we'd have
> >> to include different headers for soft-float vs hard-float, which is
> >> decided based on a macro, which is not defined for x86, and thus may
> >> redirect to the wrong (and missing) header.
> >>
> >> Instead, we notice that libtool uses the magic value 'no' to decide that
> >> a C++ compiler is not available, in which case it skeips the call to
> >> AC_PROG_CXXCPP.
> >>
> >> Given that 'no' is not provided by any package in Debian and
> >> derivatives, as well as in Fedora, we can assume that no system will
> >> have an executable called 'no'. Hence, we use that as a magic value to
> >> disable C++ detection altogether.
> >>
> >> Fixes: #10846 (again)  
> > 
> > Fixes the gnutls configure failure described in Bug-10846...
> > 
> > Tested-by: Peter Seiderer <ps.report@gmx.net>  
> 
>  Does that also imply that your earlier patch [1] can be marked as Superseded?

Yes...

Regards,
Peter

> 
>  Regards,
>  Arnout
> 
> [1] http://patchwork.ozlabs.org/patch/889057/
> 
> > 
> > Regards,
> > Peter  
> [snip]
> 

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Some packages that use libtool really need some love to be able to
 > disable C++ support.

 > This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
 > is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
 > will want a C++ preprocessor that works on valid input *and* fail on
 > invalid input.

 > So, providing 'false' as the C++ compiler will then require that we do
 > have a working C++ preprocessor. Which is totally counter-productive
 > since we do not have a C++ compiler to start with...

 > bd39d11d2e (core/infra: fix build on toolchain without C++) was a
 > previous attempt at fixing this, by using the host's C++ preprocessor.

 > However, that is very incorrect (that's my code, I can say so!) because
 > the set of defines will most probably be different for the host and the
 > target, thus causign all sorts of trouble. For example, on ARM we'd have
 > to include different headers for soft-float vs hard-float, which is
 > decided based on a macro, which is not defined for x86, and thus may
 > redirect to the wrong (and missing) header.

 > Instead, we notice that libtool uses the magic value 'no' to decide that
 > a C++ compiler is not available, in which case it skeips the call to
 > AC_PROG_CXXCPP.

 > Given that 'no' is not provided by any package in Debian and
 > derivatives, as well as in Fedora, we can assume that no system will
 > have an executable called 'no'. Hence, we use that as a magic value to
 > disable C++ detection altogether.

 > Fixes: #10846 (again)

 > Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 > Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
 > Cc: Peter Seiderer <ps.report@gmx.net>
 > Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
 > Cc: Peter Korsgaard <peter@korsgaard.com>
 > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

 > ---
 > Changes v1 -> v2:
 >   - add big fat comment...

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Some packages that use libtool really need some love to be able to
 > disable C++ support.

 > This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
 > is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
 > will want a C++ preprocessor that works on valid input *and* fail on
 > invalid input.

 > So, providing 'false' as the C++ compiler will then require that we do
 > have a working C++ preprocessor. Which is totally counter-productive
 > since we do not have a C++ compiler to start with...

 > bd39d11d2e (core/infra: fix build on toolchain without C++) was a
 > previous attempt at fixing this, by using the host's C++ preprocessor.

 > However, that is very incorrect (that's my code, I can say so!) because
 > the set of defines will most probably be different for the host and the
 > target, thus causign all sorts of trouble. For example, on ARM we'd have
 > to include different headers for soft-float vs hard-float, which is
 > decided based on a macro, which is not defined for x86, and thus may
 > redirect to the wrong (and missing) header.

 > Instead, we notice that libtool uses the magic value 'no' to decide that
 > a C++ compiler is not available, in which case it skeips the call to
 > AC_PROG_CXXCPP.

 > Given that 'no' is not provided by any package in Debian and
 > derivatives, as well as in Fedora, we can assume that no system will
 > have an executable called 'no'. Hence, we use that as a magic value to
 > disable C++ detection altogether.

This unfortunately broke jimtcl (and openocd which includes a copy of
jimtcl):

http://autobuild.buildroot.net/results/54f/54f3df03551fbdf293d33dc1e3f08005faa15321/

http://autobuild.buildroot.net/results/cbd/cbd5ab97fb0659968ff628461130627cf1745955/

Care to take a look?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCHv2] core: alternate solution to disable C++

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Some packages that use libtool really need some love to be able to
 > disable C++ support.

 > This is because libtool will want to call AC_PROG_CXXCPP as soon as CXX
 > is set non-empty to something different from 'no'. Then, AC_PROG_CXXCPP
 > will want a C++ preprocessor that works on valid input *and* fail on
 > invalid input.

 > So, providing 'false' as the C++ compiler will then require that we do
 > have a working C++ preprocessor. Which is totally counter-productive
 > since we do not have a C++ compiler to start with...

 > bd39d11d2e (core/infra: fix build on toolchain without C++) was a
 > previous attempt at fixing this, by using the host's C++ preprocessor.

 > However, that is very incorrect (that's my code, I can say so!) because
 > the set of defines will most probably be different for the host and the
 > target, thus causign all sorts of trouble. For example, on ARM we'd have
 > to include different headers for soft-float vs hard-float, which is
 > decided based on a macro, which is not defined for x86, and thus may
 > redirect to the wrong (and missing) header.

 > Instead, we notice that libtool uses the magic value 'no' to decide that
 > a C++ compiler is not available, in which case it skeips the call to
 > AC_PROG_CXXCPP.

 > Given that 'no' is not provided by any package in Debian and
 > derivatives, as well as in Fedora, we can assume that no system will
 > have an executable called 'no'. Hence, we use that as a magic value to
 > disable C++ detection altogether.

 > Fixes: #10846 (again)

 > Reported-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
 > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
 > Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
 > Cc: Peter Seiderer <ps.report@gmx.net>
 > Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
 > Cc: Peter Korsgaard <peter@korsgaard.com>
 > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

 > ---
 > Changes v1 -> v2:
 >   - add big fat comment...

Committed to 2018.02.x, thanks.

-- 
Bye, Peter Korsgaard