[Buildroot] package "expat" fails to build without a C++ compiler

[Buildroot] package "expat" fails to build without a C++ compiler

[Damien Riegel]

Hi,


I tried to build an image with the "expat" package in it, using a
toolchain without a C++ compiler. It fails with the following error:

  configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
  configure: error: C++ preprocessor "/lib/cpp" fails sanity check

Enabling C++ support fixed that error.

It's weird because the C++ preprocessor is supposed to checked by the
AC_PROG_CXXCPP macro, which is not present in configure.ac, but maybe
that macro is implied with recent versions of autotools when using
AC_PROG_CXX?

Anyways, should "expat" depends on BR2_INSTALL_LIBSTDCP?


Thank you,
-- 
Damien

[Buildroot] package "expat" fails to build without a C++ compiler

[Peter Korsgaard]

>>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:

 > Hi,
 > I tried to build an image with the "expat" package in it, using a
 > toolchain without a C++ compiler. It fails with the following error:

 >   configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
 >   configure: error: C++ preprocessor "/lib/cpp" fails sanity check

 > Enabling C++ support fixed that error.

Hmm, can you have a look in expat-2.2.4/config.log to see what exactly
goes wrong?

/lib/cpp is from your host toolchain, so enabling or not enabling C++
support shouldn't matter.

I've just tried here with a toolchain configuration without C++ support
and it works:

checking dependency style of false... none
checking how to run the C++ preprocessor... /lib/cpp
checking whether the false linker (/home/peko/source/buildroot/output-expat/host/bin/arm-linux-ld) supports shared libraries... yes
libtool.m4: error: problem compiling CXX test program
..
configure: creating ./config.status

So it complains about not being able to test C++ support, bus as expat
isn't written in C++ it doesn't matter and configure just continues.

-- 
Bye, Peter Korsgaard

[Buildroot] package "expat" fails to build without a C++ compiler

[Damien Riegel]

On Wed, Dec 20, 2017 at 09:34:12PM +0100, Peter Korsgaard wrote:
> >>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:
> 
>  > Hi,
>  > I tried to build an image with the "expat" package in it, using a
>  > toolchain without a C++ compiler. It fails with the following error:
> 
>  >   configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
>  >   configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> 
>  > Enabling C++ support fixed that error.
> 
> Hmm, can you have a look in expat-2.2.4/config.log to see what exactly
> goes wrong?
> 
> /lib/cpp is from your host toolchain, so enabling or not enabling C++
> support shouldn't matter.

/lib/cpp is the default value for the C++ preprocessor when '$CXX -E'
fails. When activating C++ support, $CXX points to a program that is
actually there, and CXXCPP doesn't default to /lib/cpp. That's why it
builds successfully when I activate C++ support.

I guess you have /lib/cpp on your machine and I don't.

I tried to remove the AC_PROG_CXX macro, but autoreconf complains that
there are C++ sources. They must be in a part of the program that isn't
built by Buildroot.

-- 
Damien

[Buildroot] package "expat" fails to build without a C++ compiler

[Peter Korsgaard]

>>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:

 > On Wed, Dec 20, 2017 at 09:34:12PM +0100, Peter Korsgaard wrote:
 >> >>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:
 >> 
 >> > Hi,
 >> > I tried to build an image with the "expat" package in it, using a
 >> > toolchain without a C++ compiler. It fails with the following error:
 >> 
 >> >   configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
 >> >   configure: error: C++ preprocessor "/lib/cpp" fails sanity check
 >> 
 >> > Enabling C++ support fixed that error.
 >> 
 >> Hmm, can you have a look in expat-2.2.4/config.log to see what exactly
 >> goes wrong?
 >> 
 >> /lib/cpp is from your host toolchain, so enabling or not enabling C++
 >> support shouldn't matter.

 > /lib/cpp is the default value for the C++ preprocessor when '$CXX -E'
 > fails. When activating C++ support, $CXX points to a program that is
 > actually there, and CXXCPP doesn't default to /lib/cpp. That's why it
 > builds successfully when I activate C++ support.

Ok. CXX actually also points to an available program when C++ support
isn't available (it points to 'false').

 > I guess you have /lib/cpp on your machine and I don't.

:/

Out of interest, what Distribution are you using?

 > I tried to remove the AC_PROG_CXX macro, but autoreconf complains that
 > there are C++ sources. They must be in a part of the program that isn't
 > built by Buildroot.

I guess that is from tests/runtestspp.cpp :/

-- 
Bye, Peter Korsgaard

[Buildroot] package "expat" fails to build without a C++ compiler

[Damien Riegel]

On Wed, Dec 20, 2017 at 10:31:45PM +0100, Peter Korsgaard wrote:
> >>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:
> 
>  > On Wed, Dec 20, 2017 at 09:34:12PM +0100, Peter Korsgaard wrote:
>  >> >>>>> "Damien" == Damien Riegel <damien.riegel@savoirfairelinux.com> writes:
>  >> 
>  >> > Hi,
>  >> > I tried to build an image with the "expat" package in it, using a
>  >> > toolchain without a C++ compiler. It fails with the following error:
>  >> 
>  >> >   configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
>  >> >   configure: error: C++ preprocessor "/lib/cpp" fails sanity check
>  >> 
>  >> > Enabling C++ support fixed that error.
>  >> 
>  >> Hmm, can you have a look in expat-2.2.4/config.log to see what exactly
>  >> goes wrong?
>  >> 
>  >> /lib/cpp is from your host toolchain, so enabling or not enabling C++
>  >> support shouldn't matter.
> 
>  > /lib/cpp is the default value for the C++ preprocessor when '$CXX -E'
>  > fails. When activating C++ support, $CXX points to a program that is
>  > actually there, and CXXCPP doesn't default to /lib/cpp. That's why it
>  > builds successfully when I activate C++ support.
> 
> Ok. CXX actually also points to an available program when C++ support
> isn't available (it points to 'false').
> 
>  > I guess you have /lib/cpp on your machine and I don't.
> 
> :/
> 
> Out of interest, what Distribution are you using?

Arch Linux

> 
>  > I tried to remove the AC_PROG_CXX macro, but autoreconf complains that
>  > there are C++ sources. They must be in a part of the program that isn't
>  > built by Buildroot.
> 
> I guess that is from tests/runtestspp.cpp :/

Indeed, when I only remove AC_PROG_CXX, it complains about
tests/Makefile.am:

  /usr/share/automake-1.15/am/depend2.am: error: am__fastdepCXX does not appear in AM_CONDITIONAL
  /usr/share/automake-1.15/am/depend2.am:   The usual way to define 'am__fastdepCXX' is to add 'AC_PROG_CXX'
  /usr/share/automake-1.15/am/depend2.am:   to 'configure.ac' and run 'aclocal' and 'autoconf' again
  tests/Makefile.am: error: C++ source seen but 'CXX' is undefined
  tests/Makefile.am:   The usual way to define 'CXX' is to add 'AC_PROG_CXX'
  tests/Makefile.am:   to 'configure.ac' and run 'autoconf' again.
  autoreconf: automake failed with exit status: 1


With the following snippet (against upstream libexpat), I can run
autoreconf and it seems to build just fine (not tested with Buildroot
yet). Does that look like an acceptable solution to you? If so, I can
provide a proper patch.

I feel like this would be a one-package-only fix. Maybe the right
solution would be to make Buildroot try to find the location of "cpp",
and set CXXCPP accordingly? (As a quick proof of concept, adding
EXPAT_CONF_ENV += CXXCPP=/usr/bin/cpp to expat.mk works)

diff --git a/expat/configure.ac b/expat/configure.ac
index 1dab0e7..d18ab3d 100644
--- a/expat/configure.ac
+++ b/expat/configure.ac
@@ -64,7 +64,6 @@ AC_SUBST(LIBAGE)

 dnl Checks for programs.
 AC_PROG_CC_C99
-AC_PROG_CXX
 AC_PROG_INSTALL

 if test "$GCC" = yes ; then
diff --git a/expat/tests/Makefile.am b/expat/tests/Makefile.am
index 742ed43..987fdd8 100644
--- a/expat/tests/Makefile.am
+++ b/expat/tests/Makefile.am
@@ -49,9 +49,6 @@ libruntests_a_SOURCES = \
 runtests_SOURCES = \
     runtests.c

-runtestspp_SOURCES = \
-    runtestspp.cpp
-
 runtests_LDADD = libruntests.a ../lib/libexpat.la
 runtestspp_LDADD = libruntests.a ../lib/libexpat.la


-- 
Damien

[Buildroot] package "expat" fails to build without a C++ compiler

[Vivien Didelot]

Hi Peter,

Damien Riegel <damien.riegel@savoirfairelinux.com> writes:

>>  >> > I tried to build an image with the "expat" package in it, using a
>>  >> > toolchain without a C++ compiler. It fails with the following error:
>>  >> 
>>  >> >   configure: error: in `/home/dkc/src/buildroot/build/build/expat-2.2.4':
>>  >> >   configure: error: C++ preprocessor "/lib/cpp" fails sanity check
>>  >> 
>>  >> > Enabling C++ support fixed that error.
>>  >> 
>>  >> Hmm, can you have a look in expat-2.2.4/config.log to see what exactly
>>  >> goes wrong?
>>  >> 
>>  >> /lib/cpp is from your host toolchain, so enabling or not enabling C++
>>  >> support shouldn't matter.
>> 
>>  > /lib/cpp is the default value for the C++ preprocessor when '$CXX -E'
>>  > fails. When activating C++ support, $CXX points to a program that is
>>  > actually there, and CXXCPP doesn't default to /lib/cpp. That's why it
>>  > builds successfully when I activate C++ support.
>> 
>> Ok. CXX actually also points to an available program when C++ support
>> isn't available (it points to 'false').
>> 
>>  > I guess you have /lib/cpp on your machine and I don't.
>> 
>> :/
>> 
>> Out of interest, what Distribution are you using?
>
> Arch Linux

I have the same issue for months now and my local fix is the following:


    --- a/package/Makefile.in
    +++ b/package/Makefile.in
    @@ -266,6 +266,7 @@ TARGET_CONFIGURE_OPTS = \
            GCC="$(TARGET_CC)" \
            CPP="$(TARGET_CPP)" \
            CXX="$(TARGET_CXX)" \
    +       CXXCPP="/usr/bin/cpp" \
            FC="$(TARGET_FC)" \
            F77="$(TARGET_FC)" \
            RANLIB="$(TARGET_RANLIB)" \
    

How would you like this to be properly fixed?


Thanks,

        Vivien