This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] test-in-container: fix Arch Linux build-programs bug?
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, DJ Delorie <dj at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 5 Sep 2018 12:52:36 +0200
- Subject: Re: [patch] test-in-container: fix Arch Linux build-programs bug?
- References: <xnzhx8cnzq.fsf@greed.delorie.com> <871f5a8b-7e90-47e7-f410-7f75b8fd2536@redhat.com> <20180831163436.68f72055@athena> <9d013c8b-d487-a144-5315-b99e6c05420a@redhat.com> <20180831185139.641fc194@athena> <alpine.DEB.2.21.1808311710340.3762@digraph.polyomino.org.uk> <20180903100925.63783162@athena> <71e876d1-81dc-0260-e117-e518182c472c@redhat.com>
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