Bug 575522 – ~sys-libs/glibc-2.21 fail to compile with gcc-4.9.3 on ARM with 'multiple definition' errors

• Status: RESOLVED NEEDINFO
• Product: Gentoo Linux

[Description Stuart Shelton 2016-02-23 21:05:51 UTC]

On both ARMv6 and ARMv7 (RPi & RPi2) platforms, glibc-2.21-r1 and glibc-2.21-r2 compile successfully using gcc-4.8.5.

However, using gcc-4.9.3 glibc fails as follows:

armv7a-hardfloat-linux-gnueabi-gcc  -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed  -nostdlib -nostartfiles -r -o work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/librtld.map.o '-Wl,-(' work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-allobjs.os work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/librtld.mapT
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/libc_pic.a(dl-addr.os): In function `_dl_addr_inside_object':
dl-addr.c:(.text+0x308): multiple definition of `_dl_addr_inside_object'
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-allobjs.os:work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-tlsdesc.os:(.text+0x13198): first defined here
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-allobjs.os:(.bss+0x90): first defined here
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/libc_pic.a(_itoa.os): In function `_itoa':
_itoa.c:(.text+0xf0): multiple definition of `_itoa'
work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-allobjs.os:work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/dl-tlsdesc.os:(.text+0x16544): first defined here
collect2: error: ld returned 1 exit status
Makefile:307: recipe for target 'work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/librtld.map' failed
make[2]: *** [work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl/elf/librtld.map] Error 1
make[2]: Leaving directory 'work/glibc-2.21/elf'
Makefile:214: recipe for target 'elf/subdir_lib' failed
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory 'work/glibc-2.21'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
make: Leaving directory 'work/build-arm-armv7a-hardfloat-linux-gnueabi-nptl'
 * ERROR: sys-libs/glibc-2.21-r2::gentoo failed (compile phase):
 *   emake failed

[Comment 1 Stuart Shelton 2016-02-23 21:06:08 UTC]

emerge --info:

Portage 2.2.26 (python 2.7.10-final-0, default/linux/arm/13.0/armv7a, gcc-4.9.3, glibc-2.21-r2, 4.1.15-v7+ armv7l)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.1.15-v7+-armv7l-with-gentoo-2.2
KiB Mem:      996872 total,    445704 free
KiB Swap:          0 total,         0 free
sh bash 4.3_p42-r1
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
distcc 3.2rc1 armv7a-hardfloat-linux-gnueabi [enabled]
app-shells/bash:          4.3_p42-r1
dev-lang/perl:            5.20.2
dev-lang/python:          2.7.10-r1
dev-util/cmake:           3.3.1-r1
dev-util/pkgconfig:       0.28-r2
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.19.1
sys-apps/sandbox:         2.10-r1
sys-devel/autoconf:       2.69
sys-devel/automake:       1.13.4, 1.14.1, 1.15
sys-devel/binutils:       2.25.1-r1
sys-devel/gcc:            4.8.5, 4.9.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.6
sys-devel/make:           4.1-r1
sys-kernel/linux-headers: 4.3 (virtual/os-headers)
sys-libs/glibc:           2.21-r2
Repositories:

gentoo
    location: /var/db/repo/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

ACCEPT_KEYWORDS="arm"
ACCEPT_LICENSE="* -@EULA"
CBUILD="armv7a-hardfloat-linux-gnueabi"
CFLAGS="-Os -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations"
CHOST="armv7a-hardfloat-linux-gnueabi"
CONFIG_PROTECT="/boot/cmdline.txt /boot/config.txt /etc /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-Os -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations"
DISTDIR="/var/cache/portage/dist"
FCFLAGS="-O2 -pipe -march=armv7-a"
FEATURES="assume-digests binpkg-logs buildpkg clean-logs collision-protect compress-build-logs config-protect-if-modified distcc distlocks ebuild-locks fail-clean fakeroot fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe -march=armv7-a"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/var/cache/portage/pkg/armv7/raspberrypi"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/cache/portage/build"
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU"
USE_PYTHON="2.7"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Build log to follow shortly...

[Comment 2 Stuart Shelton 2016-02-27 14:02:07 UTC]

I've realised that on the hosts in question I'd set the compiler to gcc-4.9.3, but on the distcc host they were set to use - even though this version was built and available - the active version was still set to gcc-4.8.5.

I'm semi-surprised that distcc doesn't use the matching compiler version, if available, or warn when version mismatches are detected.

(I guess that the identical code compiled by two compilers which share the same major version might also be anticipated to generate similar results, baring differing optimisation strategies, rather than producing objects which cannot be linked with each other?)

Leaving open in case there's any interest in following-up the distcc side of things (or any desire to forcibly disable distcc when building glibc) - but otherwise this one can be closed-off.

[Comment 3 Stuart Shelton 2016-02-28 19:46:46 UTC]

May have spoken too soon - how that the distcc build-host has been updated to use the 4.9.3 verions of gcc across the board, the ARMv7 build now appears to succeed in all circumstances.

The ARMv6 build, however, appears to be failing whenever distcc is enabled, regardless of matching versions.

(The '-march/-mcpu' flags are specified using absolute architectures rather than using '-march=native', so distcc should be able to generate deterministic code)

Generating (another) build.log...

[Comment 4 Panagiotis Christopoulos (RETIRED) 2016-02-29 18:54:31 UTC]

Well,

I'm resolving this as NEEDINFO. Reopen when you know what the problem is and on which architecture. Paste again your emerge --info output if it differs, and don't forget to update the bug subject, to briefly describe the new issue, if any.

Thank you for your report.