[Buildroot] [PATCHv2] core: alternate solution to disable C++
Peter Korsgaard
peter at korsgaard.com
Sat Mar 31 06:25:43 UTC 2018
>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at 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
More information about the buildroot
mailing list