diff mbox

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

Message ID xnzhx8cnzq.fsf@greed.delorie.com
State Committed
Commit 86de0499c3c624741bbe36927721a0cadd12e146
Headers

Commit Message

DJ Delorie Aug. 27, 2018, 6:39 a.m. UTC 
  Turns out Arch Linux uses the build-programs variable to build
different parts of glibc with different flags; but setting
build-programs to "no" also disables the default rules for programs,
leading to makefile-related errors elsewhere.

Since the "others:" target already depends on $(others) (or not) depending
on build-programs - see :

ifeq ($(build-programs),yes)
others: $(addprefix $(objpfx),$(others) $(sysdep-others) $(extra-objs))
else
others: $(addprefix $(objpfx),$(extra-objs))
endif

Setting $(others) is sufficient, and dependencies on others: are
redundant - or in this case, problematic.

Is my understanding and description accurate?

Tested via plain builds/tests with and without build-programs=no, plus
build-many-glibcs for targets x86_64-linux-gnu, i686-gnu, and
ia64-linux-gnu.

Ok to install?

	* support/Makefile (others): Don't list programs explicitly as
	a dependency of "others".

Comments

Carlos O'Donell Aug. 27, 2018, 8:08 p.m. UTC | #1 
On 08/27/2018 02:39 AM, DJ Delorie wrote:
> Turns out Arch Linux uses the build-programs variable to build
> different parts of glibc with different flags; but setting
> build-programs to "no" also disables the default rules for programs,
> leading to makefile-related errors elsewhere.
> 
> Since the "others:" target already depends on $(others) (or not) depending
> on build-programs - see :

Agreed.

> ifeq ($(build-programs),yes)
> others: $(addprefix $(objpfx),$(others) $(sysdep-others) $(extra-objs))
> else
> others: $(addprefix $(objpfx),$(extra-objs))
> endif
> 
> Setting $(others) is sufficient, and dependencies on others: are
> redundant - or in this case, problematic.

Agreed.

> Is my understanding and description accurate?

Seems accurate to me.

> Tested via plain builds/tests with and without build-programs=no, plus
> build-many-glibcs for targets x86_64-linux-gnu, i686-gnu, and
> ia64-linux-gnu.

Thanks for the testing.

> Ok to install?
> 
> 	* support/Makefile (others): Don't list programs explicitly as
> 	a dependency of "others".

OK for master.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

> diff --git a/support/Makefile b/support/Makefile
> index 0ed00212cb..b528f538a6 100644
> --- a/support/Makefile
> +++ b/support/Makefile
> @@ -168,16 +168,6 @@ LINKS_DSO_PROGRAM = links-dso-program
>  LDLIBS-links-dso-program = -lstdc++ -lgcc -lgcc_s $(libunwind)
>  endif
>  
> -others: \
> -	$(objpfx)test-container \
> -	$(objpfx)shell-container \
> -	$(objpfx)echo-container \
> -	$(objpfx)true-container \
> -	$(objpfx)$(LINKS_DSO_PROGRAM)
> -
> -ifeq ($(build-programs),yes)
> -endif
> -
>  LDLIBS-test-container = $(libsupport)
>  
>  others += test-container
>
Albert ARIBAUD Aug. 31, 2018, 2:34 p.m. UTC | #2 
Hi,

From commit 561b0bec444 onward, my cross-build for ARM target from X64
host started failing with the following error:

arm-linux-gnueabi-gcc -nostdlib -nostartfiles
-o /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program
-Wl,-z,combreloc -Wl,-z,relro
-Wl,--hash-style=both /home/3adev/src/siemens/y2038/glibc/build/csu/crt1.o /home/3adev/src/siemens/y2038/glibc/build/csu/crti.o
`arm-linux-gnueabi-gcc  --print-file-name=crtbegin.o` /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o -lstdc++ -lgcc_s -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-rpath-link=/home/3adev/src/siemens/y2038/glibc/build:/home/3adev/src/siemens/y2038/glibc/build/math:/home/3adev/src/siemens/y2038/glibc/build/elf:/home/3adev/src/siemens/y2038/glibc/build/dlfcn:/home/3adev/src/siemens/y2038/glibc/build/nss:/home/3adev/src/siemens/y2038/glibc/build/nis:/home/3adev/src/siemens/y2038/glibc/build/rt:/home/3adev/src/siemens/y2038/glibc/build/resolv:/home/3adev/src/siemens/y2038/glibc/build/mathvec:/home/3adev/src/siemens/y2038/glibc/build/support:/home/3adev/src/siemens/y2038/glibc/build/crypt:/home/3adev/src/siemens/y2038/glibc/build/nptl /home/3adev/src/siemens/y2038/glibc/build/libc.so.6 /home/3adev/src/siemens/y2038/glibc/build/libc_nonshared.a -Wl,--as-needed /home/3adev/src/siemens/y2038/glibc/build/elf/ld.so -Wl,--no-as-needed -lgcc /home/3adev/src/siemens/y2038/glibc/build/elf/libgcc-stubs.a `arm-linux-gnueabi-gcc  --print-file-name=crtend.o` /home/3adev/src/siemens/y2038/glibc/build/csu/crtn.o
/home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o:
file not recognized: Format de fichier non reconnu

(build is French; this means unrecognized file format)

Doing a

	$ file support/*.o

Results in:

support/echo-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
version 1 (SYSV), with debug_info, not stripped
support/links-dso-program.o: ELF 64-bit LSB relocatable, x86-64,
version 1 (SYSV), with debug_info, not stripped
support/shell-container.o:   ELF 32-bit LSB relocatable, ARM, EABI5
version 1 (SYSV), with debug_info, not stripped
support/stamp.o:             empty
support/test-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
version 1 (SYSV), with debug_info, not stripped
support/true-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
version 1 (SYSV), with debug_info, not stripped

Apparently, links-dso-program.o is built native for x86-64 then linked
for ARM.

Did the way to cross-build change with the advent of test-in-container?

Cordialement,
Albert ARIBAUD
3ADEV
Carlos O'Donell Aug. 31, 2018, 4:21 p.m. UTC | #3 
On 08/31/2018 10:34 AM, Albert ARIBAUD wrote:
> Hi,

> 

> From commit 561b0bec444 onward, my cross-build for ARM target from X64

> host started failing with the following error:

> 

> arm-linux-gnueabi-gcc -nostdlib -nostartfiles


OK.

> -o /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program

> -Wl,-z,combreloc -Wl,-z,relro

> -Wl,--hash-style=both /home/3adev/src/siemens/y2038/glibc/build/csu/crt1.o /home/3adev/src/siemens/y2038/glibc/build/csu/crti.o

> `arm-linux-gnueabi-gcc  --print-file-name=crtbegin.o` /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o -lstdc++ -lgcc_s -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-rpath-link=/home/3adev/src/siemens/y2038/glibc/build:/home/3adev/src/siemens/y2038/glibc/build/math:/home/3adev/src/siemens/y2038/glibc/build/elf:/home/3adev/src/siemens/y2038/glibc/build/dlfcn:/home/3adev/src/siemens/y2038/glibc/build/nss:/home/3adev/src/siemens/y2038/glibc/build/nis:/home/3adev/src/siemens/y2038/glibc/build/rt:/home/3adev/src/siemens/y2038/glibc/build/resolv:/home/3adev/src/siemens/y2038/glibc/build/mathvec:/home/3adev/src/siemens/y2038/glibc/build/support:/home/3adev/src/siemens/y2038/glibc/build/crypt:/home/3adev/src/siemens/y2038/glibc/build/nptl /home/3adev/src/siemens/y2038/glibc/build/libc.so.6 /home/3adev/src/siemens/y2038/glibc/build/libc_nonshared.a -Wl,--as-needed /home/3adev/src/siemens/y2038/glibc/build/elf/ld.so -Wl,--no-as-needed -lgcc /home/3adev/src/siemens/y2038/glibc/build/elf/libgcc-stubs.a `arm-linux-gnueabi-gcc  --print-file-name=crtend.o` /home/3adev/src/siemens/y2038/glibc/build/csu/crtn.o

> /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o:

> file not recognized: Format de fichier non reconnu

> 

> (build is French; this means unrecognized file format)

> 

> Doing a

> 

> 	$ file support/*.o

> 

> Results in:

> 

> support/echo-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5

> version 1 (SYSV), with debug_info, not stripped

> support/links-dso-program.o: ELF 64-bit LSB relocatable, x86-64,

> version 1 (SYSV), with debug_info, not stripped

> support/shell-container.o:   ELF 32-bit LSB relocatable, ARM, EABI5

> version 1 (SYSV), with debug_info, not stripped

> support/stamp.o:             empty

> support/test-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5

> version 1 (SYSV), with debug_info, not stripped

> support/true-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5

> version 1 (SYSV), with debug_info, not stripped

> 

> Apparently, links-dso-program.o is built native for x86-64 then linked

> for ARM.

> 

> Did the way to cross-build change with the advent of test-in-container?


No. It did not change. We test with build-many-glibcs all the time to do
cross-testing to all of the available ABI targets.

How exactly did you configure glibc?

-- 
Cheers,
Carlos.
Albert ARIBAUD Aug. 31, 2018, 4:51 p.m. UTC | #4 
Hi Carlos,

Le Fri, 31 Aug 2018 12:21:56 -0400, Carlos O'Donell <carlos@redhat.com>
a écrit :

> On 08/31/2018 10:34 AM, Albert ARIBAUD wrote:
> > Hi,
> > 
> > From commit 561b0bec444 onward, my cross-build for ARM target from X64
> > host started failing with the following error:
> > 
> > arm-linux-gnueabi-gcc -nostdlib -nostartfiles  
> 
> OK.
> 
> > -o /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program
> > -Wl,-z,combreloc -Wl,-z,relro
> > -Wl,--hash-style=both /home/3adev/src/siemens/y2038/glibc/build/csu/crt1.o /home/3adev/src/siemens/y2038/glibc/build/csu/crti.o
> > `arm-linux-gnueabi-gcc  --print-file-name=crtbegin.o` /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o -lstdc++ -lgcc_s -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-rpath-link=/home/3adev/src/siemens/y2038/glibc/build:/home/3adev/src/siemens/y2038/glibc/build/math:/home/3adev/src/siemens/y2038/glibc/build/elf:/home/3adev/src/siemens/y2038/glibc/build/dlfcn:/home/3adev/src/siemens/y2038/glibc/build/nss:/home/3adev/src/siemens/y2038/glibc/build/nis:/home/3adev/src/siemens/y2038/glibc/build/rt:/home/3adev/src/siemens/y2038/glibc/build/resolv:/home/3adev/src/siemens/y2038/glibc/build/mathvec:/home/3adev/src/siemens/y2038/glibc/build/support:/home/3adev/src/siemens/y2038/glibc/build/crypt:/home/3adev/src/siemens/y2038/glibc/build/nptl /home/3adev/src/siemens/y2038/glibc/build/libc.so.6 /home/3adev/src/siemens/y2038/glibc/build/libc_nonshared.a -Wl,--as-needed /home/3adev/src/siemens/y2038/glibc/build/elf/ld.so -Wl,--no-as-needed -lgcc /home/3adev/src/siemens/y2038/glibc/build/elf/libgcc-stubs.a `arm-linux-gnueabi-gcc  --print-file-name=crtend.o` /home/3adev/src/siemens/y2038/glibc/build/csu/crtn.o
> > /home/3adev/src/siemens/y2038/glibc/build/support/links-dso-program.o:
> > file not recognized: Format de fichier non reconnu
> > 
> > (build is French; this means unrecognized file format)
> > 
> > Doing a
> > 
> > 	$ file support/*.o
> > 
> > Results in:
> > 
> > support/echo-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
> > version 1 (SYSV), with debug_info, not stripped
> > support/links-dso-program.o: ELF 64-bit LSB relocatable, x86-64,
> > version 1 (SYSV), with debug_info, not stripped
> > support/shell-container.o:   ELF 32-bit LSB relocatable, ARM, EABI5
> > version 1 (SYSV), with debug_info, not stripped
> > support/stamp.o:             empty
> > support/test-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
> > version 1 (SYSV), with debug_info, not stripped
> > support/true-container.o:    ELF 32-bit LSB relocatable, ARM, EABI5
> > version 1 (SYSV), with debug_info, not stripped
> > 
> > Apparently, links-dso-program.o is built native for x86-64 then linked
> > for ARM.
> > 
> > Did the way to cross-build change with the advent of test-in-container?  
> 
> No. It did not change. We test with build-many-glibcs all the time to do
> cross-testing to all of the available ABI targets.
> 
> How exactly did you configure glibc?

Makefile has these vars:

	export ROOTFS_DIR_Y2038        := $(PWD)/rootfs-y2038
	export KERNEL_HDR_DIR_Y2038    := $(ROOTFS_DIR_Y2038)/usr
	TARGET_ARCH = arm-linux-gnueabi
	GLIBC_HOST = $(TARGET_ARCH)
	GLIBC_SOURCE_DIR        := $(PWD)/glibc/src
	GLIBC_BUILD_DIR         := $(PWD)/glibc/build

And executes these two commands:

	mkdir -p $(GLIBC_BUILD_DIR)
	cd $(GLIBC_BUILD_DIR) && $(GLIBC_SOURCE_DIR)/configure \
	--prefix=/usr --host=$(GLIBC_HOST) \
	--with-headers=$(KERNEL_HDR_DIR_Y2038)/include \
	libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

I always remove $(PWD)/glibc/build before I run the commands above.

Cordialement,
Albert ARIBAUD
3ADEV
Joseph Myers Aug. 31, 2018, 5:12 p.m. UTC | #5 
On Fri, 31 Aug 2018, Albert ARIBAUD wrote:

> 	libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

This doesn't explain your problem, but you shouldn't need those settings 
for any glibc version from after March 2012.
Carlos O'Donell Aug. 31, 2018, 5:16 p.m. UTC | #6 
On 08/31/2018 12:51 PM, Albert ARIBAUD wrote:
> Makefile has these vars:
> 
> 	export ROOTFS_DIR_Y2038        := $(PWD)/rootfs-y2038
> 	export KERNEL_HDR_DIR_Y2038    := $(ROOTFS_DIR_Y2038)/usr
> 	TARGET_ARCH = arm-linux-gnueabi
> 	GLIBC_HOST = $(TARGET_ARCH)
> 	GLIBC_SOURCE_DIR        := $(PWD)/glibc/src
> 	GLIBC_BUILD_DIR         := $(PWD)/glibc/build
> 
> And executes these two commands:
> 
> 	mkdir -p $(GLIBC_BUILD_DIR)
> 	cd $(GLIBC_BUILD_DIR) && $(GLIBC_SOURCE_DIR)/configure \
> 	--prefix=/usr --host=$(GLIBC_HOST) \
> 	--with-headers=$(KERNEL_HDR_DIR_Y2038)/include \
> 	libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
> 
> I always remove $(PWD)/glibc/build before I run the commands above.

OK, I'm trying to reproduce this now. I'll tell you how far I get.
Albert ARIBAUD Sept. 3, 2018, 8:09 a.m. UTC | #7 
Hi Joseph,

Le Fri, 31 Aug 2018 17:12:07 +0000, Joseph Myers
<joseph@codesourcery.com> a écrit :

> On Fri, 31 Aug 2018, Albert ARIBAUD wrote:
> 
> > 	libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes  
> 
> This doesn't explain your problem, but you shouldn't need those settings 
> for any glibc version from after March 2012.

Thanks. I removed them and indeed it has no influence on builds, which
build until commit 561b0bec, then fail with the same error regarding
links-dso-program.o.

Cordialement,
Albert ARIBAUD
3ADEV
Carlos O'Donell Sept. 4, 2018, 8:55 p.m. UTC | #8 
On 09/03/2018 04:09 AM, Albert ARIBAUD wrote:
> Hi Joseph,

> 

> Le Fri, 31 Aug 2018 17:12:07 +0000, Joseph Myers

> <joseph@codesourcery.com> a écrit :

> 

>> On Fri, 31 Aug 2018, Albert ARIBAUD wrote:

>>

>>> 	libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes  

>>

>> This doesn't explain your problem, but you shouldn't need those settings 

>> for any glibc version from after March 2012.

> 

> Thanks. I removed them and indeed it has no influence on builds, which

> build until commit 561b0bec, then fail with the same error regarding

> links-dso-program.o.


OK, so 32-bit ARM:

~/src/glibc/scripts/build-many-glibcs.py --keep all -j 8 . glibcs arm-linux-gnueabi
PASS: glibcs-arm-linux-gnueabi check-compilers
PASS: glibcs-arm-linux-gnueabi rm
PASS: glibcs-arm-linux-gnueabi mkdir
PASS: glibcs-arm-linux-gnueabi copy-rm
PASS: glibcs-arm-linux-gnueabi copy-mkdir
PASS: glibcs-arm-linux-gnueabi copy
PASS: glibcs-arm-linux-gnueabi configure
PASS: glibcs-arm-linux-gnueabi build
PASS: glibcs-arm-linux-gnueabi install
PASS: glibcs-arm-linux-gnueabi mkdir-lib
PASS: glibcs-arm-linux-gnueabi check
PASS: glibcs-arm-linux-gnueabi save-logs
[carlos@athas build-many-glibcs]$ echo $?
0

My cross builds of glibc (without testing) succeed.

Using build-many-glibcs.py is our standard way to ensure that the workflow
works.

We are going to need exact steps from you and probably snippets of build
logs to figure out what is going on.

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

So is the final link:

arm-glibc-linux-gnueabi-gcc -nostdlib -nostartfiles -o /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support/links-dso-program    -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/csu/crt1.o /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/csu/crti.o `arm-glibc-linux-gnueabi-gcc  --print-file-name=crtbegin.o` /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support/links-dso-program.o -lstdc++ -lgcc -lgcc_s  -Wl,-dynamic-linker=/lib/ld-linux.so.3 -Wl,-rpath-link=/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/math:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/elf:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/dlfcn:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/nss:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/nis:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/rt:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/resolv:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/mathvec:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/support:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/crypt:/mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/nptl /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/libc.so.6 /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/libc_nonshared.a -Wl,--as-needed /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/elf/ld.so -Wl,--no-as-needed -lgcc /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/elf/libgcc-stubs.a `arm-glibc-linux-gnueabi-gcc  --print-file-name=crtend.o` /mnt/ssd/carlos/build/build-many-glibcs/build/glibcs/arm-linux-gnueabi/glibc/csu/crtn.o

-- 
Cheers,
Carlos.
Albert ARIBAUD Sept. 5, 2018, 10:52 a.m. UTC | #9 
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
Albert ARIBAUD Sept. 5, 2018, 4:30 p.m. UTC | #10 
On Wed, 5 Sep 2018 12:52:36 +0200, Albert ARIBAUD
<albert.aribaud@3adev.fr> wrote :

> 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.

Just in case someone googling for the same type of issue reads this: DJ
pointed me to the cause and suggested a workaround (thanks you DJ!)

Apparently, the glibc configure process correctly guesses the C cross
compiler from host (and sets CC accordingly by itself it it was not set
already), but it might fail to guess the C++ cross compiler even though
it is present (and in the PATH), and it will then set CXX to g++. This
is what is happening in my case.

The workaround is to manually pre-set CXX=arm-linux-gnueabi-g++ and
export it (hence overriding any configure guesswork about the C++
compiler). If I do this, then the build failure disappears.

Cordialement,
Albert ARIBAUD
3ADEV
Joseph Myers Sept. 5, 2018, 4:49 p.m. UTC | #11 
On Wed, 5 Sep 2018, Albert ARIBAUD wrote:

> The workaround is to manually pre-set CXX=arm-linux-gnueabi-g++ and
> export it (hence overriding any configure guesswork about the C++
> compiler). If I do this, then the build failure disappears.

Exporting the variables in the environment is another obsolescent practice 
(setting them on the configure command line, as arguments to configure, is 
preferred for configure scripts generated with autoconf 2.50 or later).  
(See NEWS for autoconf 2.50, released in 2001.)
diff mbox

Patch

diff --git a/support/Makefile b/support/Makefile
index 0ed00212cb..b528f538a6 100644
--- a/support/Makefile
+++ b/support/Makefile
@@ -168,16 +168,6 @@  LINKS_DSO_PROGRAM = links-dso-program
 LDLIBS-links-dso-program = -lstdc++ -lgcc -lgcc_s $(libunwind)
 endif
 
-others: \
-	$(objpfx)test-container \
-	$(objpfx)shell-container \
-	$(objpfx)echo-container \
-	$(objpfx)true-container \
-	$(objpfx)$(LINKS_DSO_PROGRAM)
-
-ifeq ($(build-programs),yes)
-endif
-
 LDLIBS-test-container = $(libsupport)
 
 others += test-container