[patch] test-in-container: fix Arch Linux build-programs bug?

[Albert ARIBAUD]

Hi Carlos,

On Tue, 4 Sep 2018 16:55:07 -0400, Carlos O'Donell <carlos@redhat.com>
wrote :

> The compile is fine for me:
> arm-glibc-linux-gnueabi-g++ links-dso-program.cc -c
> -I/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/
> -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants
> -frounding-math -fno-stack-protector          -I../include
> -I/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support
> -I/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc
> -I../sysdeps/unix/sysv/linux/arm  -I../sysdeps/arm/nptl
> -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
> -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu
> -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
> -I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix
> -I../sysdeps/arm/nofpu  -I../sysdeps/ieee754/soft-fp
> -I../sysdeps/arm/include -I../sysdeps/arm  -I../sysdeps/wordsize-32
> -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64
> -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.
> -D_LIBC_REENTRANT
> -include /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/libc-modules.h
> -DMODULE_NAME=nonlib -include ../include/libc-symbols.h
> -DTOP_NAMESPACE=glibc
> -o /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support/links-dso-program.o
> -MD -MP
> -MF /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support/links-dso-program.o.dt
> -MT /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support/links-dso-program.o

On my side, this starts with "g++ links-dso-program.cc ...", which
confirms that this source file gets compiled with the build host native
compiler while the other files in the same directory get compiled with
the target host cross compiler (and the binaries all get linked with
the cross linker).

Now the question becomes: why is the build host native compiler used
for links-dso-program.cc? Its only unique quality is to be C++, not C.

Here is my glibc build process, starting with a
clean glibc source tree at /src/y2038/glibc/src, and a nonexistent 
/src/y2038/glibc/build:

    mkdir -p /src/y2038/glibc/build

    cd /src/y2038/glibc/build
    && /src/y2038/glibc/src/configure --prefix=/usr
    --host=arm-linux-gnueabi
    --with-headers=/src/rootfs-y2038/usr/include

    make -C /src/y2038/glibc/build

When these commands are run, I have the following env vars set:

CROSS_COMPILE=arm-linux-gnueabi-
CC=arm-linux-gnueabi-gcc
LD=arm-linux-gnueabi-ld

They probably don't matter to glibc (as the cross tool names probably
derive from --host) but they are used by other SW components which I
also cross-build.

arm-linux-gnueabi-gcc -v indicates version 7.3.0

Cordialement,
Albert ARIBAUD
3ADEV