core: alternate solution to disable C++

PATCH Superseded Yann E. MORIN 6 participants 10 messages Mar 27, 2018 – Apr 7, 2018

lore

Share & tools

lore

Yann E. MORIN

author

2018-03-27 11:00 UTC #0 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

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 <[email protected]>

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Damien Riegel <[email protected]>

Cc Peter Seiderer <[email protected]>

Cc Vivien Didelot <[email protected]>

Cc Peter Korsgaard <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

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

package/Makefile.in +9 -1

index e387ce67fe..57fb47ea2e 100644
@@ -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)

Signature · 1 line

2.14.1

Baruch Siach

2018-03-27 12:04 UTC #1 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

Hi Yann,

Quoted 58 lines · 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 <[email protected]>
Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Damien Riegel <[email protected]>
Cc Peter Seiderer <[email protected]>
Cc Vivien Didelot <[email protected]>
Cc Peter Korsgaard <[email protected]>
Cc Thomas Petazzoni <[email protected]>
---
Changes v1 -> v2:
- add big fat comment...
---
 package/Makefile.in | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
package/Makefile.in +1 -0
index e387ce67fe..57fb47ea2e 100644
@@ -409,8 +409,16 @@ else
 NLS_OPTS = --disable-nls
 endif
 
+# We need anything that is invalid. Traditionally, we'd have used 'false' (and

package/Makefile.in else · line 421

Quoted 10 lines

package/Makefile.in +8 -1

+# 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'.

package/Makefile.in else · line 424

Quoted 3 lines

package/Makefile.in +0 -0
 endif
 
 ifeq ($(BR2_STATIC_LIBS),y)

baruch

Signature · 3 lines

     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 -

Thomas Petazzoni

2018-03-27 12:43 UTC #2 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

Hello,

Quoted 27 lines · Baruch Siach

Hi Yann,
Quoted 24 lines · 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

skeips -> skips

Quoted 5 lines

package/Makefile.in +5 -0

+# 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

Quoted 8 lines

package/Makefile.in else · line 421

Quoted 6 lines

package/Makefile.in +4 -1

+# 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

Signature · 3 lines

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

Yann E. MORIN

author

2018-03-27 17:49 UTC #3 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

Thomas, Baruch,

On 2018-03-27 14:43 +0200, Thomas Petazzoni spake thusly:

Quoted 14 lines · Baruch Siach

Quoted 13 lines · Yann E. MORIN
Quoted 12 lines
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...

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
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/

Quoted 7 lines

Quoted 6 lines
Quoted 6 lines
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.

Quoted 14 lines

Quoted 5 lines

package/Makefile.in +5 -0

+# 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

Quoted 8 lines

package/Makefile.in else · line 421

Quoted 6 lines

package/Makefile.in +4 -1

+# 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'.

Quoted 4 lines

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.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

Peter Seiderer

2018-03-27 19:40 UTC #4 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

In reply to Yann E. MORIN

Hello Yann,

Quoted 26 lines · 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.

Quoted 6 lines

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 <[email protected]>

Regards,
Peter

Quoted 39 lines

Reported-by Damien Riegel <[email protected]>

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Damien Riegel <[email protected]>

Cc Peter Seiderer <[email protected]>

Cc Vivien Didelot <[email protected]>

Cc Peter Korsgaard <[email protected]>

Cc Thomas Petazzoni <[email protected]>

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

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

package/Makefile.in +9 -1

index e387ce67fe..57fb47ea2e 100644
@@ -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)

Arnout Vandecappelle

2018-03-28 22:08 UTC #5 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

Quoted 35 lines · Peter Seiderer

Hello Yann,
Quoted 31 lines · 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.

Quoted 5 lines

Quoted 1 line
Fixes #10846 (again)
Fixes the gnutls configure failure described in Bug-10846...
Tested-by Peter Seiderer <[email protected]>

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

Regards,
Arnout

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

Quoted 3 lines

Regards,
Peter

[snip]

Signature · 6 lines

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

Peter Seiderer

2018-03-29 16:25 UTC #6 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

Quoted 36 lines · Arnout Vandecappelle

Quoted 35 lines · Peter Seiderer
Hello Yann,
Quoted 31 lines · 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.

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
Fixes #10846 (again)
Fixes the gnutls configure failure described in Bug-10846...
Tested-by Peter Seiderer <[email protected]>
Does that also imply that your earlier patch [1] can be marked as Superseded?

Yes...

Regards,
Peter

Quoted 11 lines

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

Peter Korsgaard

2018-03-30 12:25 UTC #7 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

In reply to Yann E. MORIN

Quoted 43 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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 <[email protected]>
Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Damien Riegel <[email protected]>
Cc Peter Seiderer <[email protected]>
Cc Vivien Didelot <[email protected]>
Cc Peter Korsgaard <[email protected]>
Cc Thomas Petazzoni <[email protected]>

Quoted 3 lines

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

Committed, thanks.

Signature · 1 line

Bye, Peter Korsgaard

Peter Korsgaard

2018-03-31 06:25 UTC #8 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

In reply to Yann E. MORIN

Quoted 24 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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.

Quoted 8 lines

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?

Signature · 1 line

Bye, Peter Korsgaard

Peter Korsgaard

2018-04-07 15:41 UTC #9 lore raw

PATCH v2 1/1 core: alternate solution to disable C++

In reply to Yann E. MORIN

Quoted 43 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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 <[email protected]>
Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Damien Riegel <[email protected]>
Cc Peter Seiderer <[email protected]>
Cc Vivien Didelot <[email protected]>
Cc Peter Korsgaard <[email protected]>
Cc Thomas Petazzoni <[email protected]>

Quoted 3 lines

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

Committed to 2018.02.x, thanks.

Signature · 1 line

Bye, Peter Korsgaard