Bug 697685 - gcc 4.5.1 doesn't compile on arm 5tel
gcc 4.5.1 doesn't compile on arm 5tel
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
14
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2011-04-18 18:11 EDT by Peter Robinson
Modified: 2011-08-06 14:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-31 11:57:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
[PATCH] Pass --allow-multiple-definition to the linker when compiling libgcc_post_upgrade (1.30 KB, patch)
2011-05-22 12:29 EDT, Niels de Vos
no flags Details | Diff

  None (edit)
Description Peter Robinson 2011-04-18 18:11:18 EDT
gcc 4.4.5 on dist-f13 compiles fine.

gcc-4.5.1-4 and gcc-4.5.1-5 on dist-f14 fails at the excerpt below. There are no later versions in dist-f14. I've not tried upstream 4.5.[23].

Full log: http://arm.koji.fedoraproject.org/koji/getfile?taskID=93203&name=build.log

Excerpt:

+ for h in '`find $FULLPATH/include -name \*.h`'
+ grep -q 'It has been auto-edited by fixincludes from' /builddir/build/BUILDROOT/gcc-4.5.1-4.fc14.arm/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.5.1/include/ssp/stdio.h
+ cat
+ cat
+ chmod 755 /builddir/build/BUILDROOT/gcc-4.5.1-4.fc14.arm/usr/bin/c89 /builddir/build/BUILDROOT/gcc-4.5.1-4.fc14.arm/usr/bin/c99
+ mkdir -p /builddir/build/BUILDROOT/gcc-4.5.1-4.fc14.arm/usr/sbin
+ gcc -static -Os /builddir/build/SOURCES/libgcc_post_upgrade.c -o /builddir/build/BUILDROOT/gcc-4.5.1-4.fc14.arm/usr/sbin/libgcc_post_upgrade
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/../../../libc.a(libc-start.o): In function `__libc_start_main':
(.text+0x0): multiple definition of `__libc_start_main'
/tmp/ccefAKvc.o:libgcc_post_upgrade.c:(.text+0x8c): first defined here
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/../../../libc.a(elf-init.o): In function `__libc_csu_fini':
(.text+0x4): multiple definition of `__libc_csu_fini'
/tmp/ccefAKvc.o:libgcc_post_upgrade.c:(.text+0x80): first defined here
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/../../../libc.a(elf-init.o): In function `__libc_csu_init':
(.text+0x40): multiple definition of `__libc_csu_init'
/tmp/ccefAKvc.o:libgcc_post_upgrade.c:(.text+0x7c): first defined here
collect2: ld returned 1 exit status
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.E4Lm2k (%install)
    Bad exit status from /var/tmp/rpm-tmp.E4Lm2k (%install)
Child returncode was: 1
Comment 1 Niels de Vos 2011-05-22 12:29:20 EDT
Created attachment 500281 [details]
[PATCH] Pass --allow-multiple-definition to the linker when compiling libgcc_post_upgrade


Linking libgcc_post_upgrade fails because there are multiple definitions
of __libc_start_main, __libc_csu_fini and __libc_csu_init. These functions
are defined in libgcc_post_upgrade.c and in libc.a.

From "man ld" on --allow-multiple-definition:
> Normally when a symbol is defined multiple times, the linker will
> report a fatal error. These options allow multiple definitions and the
> first definition will be used.

I do not think this should be a final solution, but at least it makes it
possible to build gcc on ARM.
---
 gcc.spec |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)
Comment 2 Jakub Jelinek 2011-05-31 11:57:02 EDT
gcc-4.6.0-9 doesn't have libgcc_post_upgrade any longer, being replaced by <lua> scriptlet.  SO this problem is gone in F15 updates testing and F16.

Note You need to log in before you can comment on or make changes to this bug.