For the sake of completeness: glibc-2.28 worked like a charm with "--enable-languages=c"

What's the value of CXX in config.make?  What does config.log show about the detected C++ compiler?  Thanks.

Hi!

Here is the output of config.log:

configure:2610: $? = 0
configure:2599: arm-linux-gnueabi-gcc -v >&5
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/working_dir/Desktop/work/priv/gcc_builds/toolchain/libexec/gcc/arm-linux-gnueabi/8.2.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: /working_dir/Desktop/work/priv/gcc_builds/sources/gcc-gcc-8.2.0/configure --target=arm-linux-gnueabi --prefix=/working_dir/Desktop/work/priv/gcc_builds/toolchain --disable-nls --enable-languages=c
Thread model: posix
gcc version 8.2.0 (GCC)
configure:2610: $? = 0
configure:2599: arm-linux-gnueabi-gcc -V >&5
arm-linux-gnueabi-gcc: error: unrecognized command line option '-V'
arm-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
configure:2610: $? = 1
configure:2599: arm-linux-gnueabi-gcc -qversion >&5
arm-linux-gnueabi-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
arm-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
configure:2610: $? = 1
configure:2615: checking for suffix of object files
configure:2637: arm-linux-gnueabi-gcc -c   conftest.c >&5
configure:2641: $? = 0
configure:2662: result: o
configure:2666: checking whether we are using the GNU C compiler
configure:2685: arm-linux-gnueabi-gcc -c   conftest.c >&5
configure:2685: $? = 0
configure:2694: result: yes
configure:2703: checking whether arm-linux-gnueabi-gcc accepts -g
configure:2723: arm-linux-gnueabi-gcc -c -g  conftest.c >&5
configure:2723: $? = 0
configure:2764: result: yes
configure:2793: checking for gcc
configure:2809: found /usr/bin/gcc
configure:2820: result: gcc
configure:2844: checking for arm-linux-gnueabi-readelf
configure:2860: found /working_dir/Desktop/work/priv/gcc_builds/toolchain/bin/arm-linux-gnueabi-readelf
configure:2871: result: arm-linux-gnueabi-readelf
configure:2949: checking for arm-linux-gnueabi-g++
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-c++
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-gpp
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-aCC
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-CC
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-cxx
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-cc++
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-cl.exe
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-FCC
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-KCC
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-RCC
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-xlC_r
configure:2979: result: no
configure:2949: checking for arm-linux-gnueabi-xlC
configure:2979: result: no
configure:2993: checking for g++
configure:3009: found /usr/bin/g++
configure:3020: result: g++
configure:3047: checking for C++ compiler version
configure:3056: g++ --version >&5
g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


config.make detects:
CXX = g++

Hm.. It seems the build gets poisoned by the host compiler...

Or is this even the normal behavior?

Unknown at this point.  How do you invoke configure?  Which arguments do you specify, and do you set any environment variables?  Thanks.

See <https://sourceware.org/ml/libc-alpha/2018-09/msg00054.html>.  I don't 
see such an issue when using the build process from build-many-glibcs.py 
for building the initial glibc with a C-only compiler.

I don not set any environment variables. It's just a plain debian9 docker session. 

I configure the glibc with this:

/home/work_dir/sources/glibc-glibc-2.29/configure --host=arm-linux-gnueabi --target=arm-linux-gnueabi --prefix=/home/work_dir/toolchain/arm-linux-gnueabi --with-headers=/home/work_dir/toolchain/arm-linux-gnueabi/include libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

The problem definitely arose with glibc-2.29 with glibc-2.28 it works without any problem.

On Wed, 6 Feb 2019, franz.flasch at gmx dot at wrote:

> /home/work_dir/sources/glibc-glibc-2.29/configure --host=arm-linux-gnueabi
> --target=arm-linux-gnueabi --prefix=/home/work_dir/toolchain/arm-linux-gnueabi

glibc is not a compilation tool, so --target= should not be used when 
configuring it.

> libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

These settings are obsolete for all glibc versions from after March 2012.

OK, thanks for the hint. Will test with the updated configure args.

Still the same problem: Here is the complete steps I use in my cross toolchain build:

1. Binutils:
/working_dir/Desktop/work/private/gcc_toolchain_builds/sources/binutils-2.32/configure --target=arm-linux-gnueabi --prefix=/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain --disable-nls --disable-werror
make all
make install

2. Linux Header:
make ARCH=arm INSTALL_HDR_PATH=/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/arm-linux-gnueabi headers_install -j9

3. GCC pass 1:
/working_dir/Desktop/work/private/gcc_toolchain_builds/sources/gcc-gcc-8.2.0/configure --target=arm-linux-gnueabi --prefix=/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain --disable-nls --enable-languages=c
make all-gcc
make install-gcc

4. glibc header:
/working_dir/Desktop/work/private/gcc_toolchain_builds/sources/glibc-glibc-2.29/configure --host=arm-linux-gnueabi --prefix=/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/arm-linux-gnueabi --with-headers=/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/arm-linux-gnueabi/include
make install-bootstrap-headers=yes install-headers
make -j9 csu/subdir_lib
install csu/crt1.o csu/crti.o csu/crtn.o /working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/arm-linux-gnueabi/lib
/working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/bin/arm-linux-gnueabi-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o /working_dir/Desktop/work/private/gcc_toolchain_builds/toolchain/arm-linux-gnueabi/lib/libc.so

5. GCC pass 2
make -j9 all-target-libgcc
make install-target-libgcc

6. glibc:
make -j9

- Here is where the error occurs. With glibc-2.28 it succeeds. Also this step succeeds with glibc-2.29, if configured with "--enable-languages=c,c++"

If i patch the files Makefile at line 363 to "LINKS_DSO_PROGRAM = links-dso-program-c" and the same with support/Makefile at line 175 it also works. This links-dso-program stuff was added with glibc-2.29 as i cannot find any reference to it in glibc-2.28.

It seems, that during the build, he believes that he can use the host c++ compiler for that. Is there any way to unset CXX during build? What is the intended way to crosscompile glibc without c++ enabled?

Update: If I set CXX=arm-linux-gnueabi-g++ during configure it works! Even if (or because) arm-linux-gnueabi-g++ does not exist! Is this the expected behaviour? At least it is a workaround...

Perhaps the configure test should also make sure that the C++ compiler can 
link with an object built by the C compiler (or vice versa), and disregard 
any C++ compiler found that can't so link.

(In reply to joseph@codesourcery.com from comment #13)
> Perhaps the configure test should also make sure that the C++ compiler can 
> link with an object built by the C compiler (or vice versa), and disregard 
> any C++ compiler found that can't so link.

I expected AC_PROG_CXX would do this, but it does not.  I'm not sure if it makes sense to write a custom check for this at this point.

I can confirm that setting CXX fixes the compilation.