Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 246800 - gcc: please add arm support
Summary: gcc: please add arm support
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 8
Hardware: arm9
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2007-07-05 00:01 UTC by Lennert Buytenhek
Modified: 2008-11-26 11:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-26 11:19:20 UTC
Type: ---

Attachments (Terms of Use)
Make building objc conditional. (3.79 KB, patch)
2007-07-05 00:01 UTC, Lennert Buytenhek
no flags Details | Diff
Spec file diffs for ARM. (2.15 KB, patch)
2007-07-05 00:04 UTC, Lennert Buytenhek
no flags Details | Diff
PR28516 fix. (669 bytes, patch)
2007-07-05 00:05 UTC, Lennert Buytenhek
no flags Details | Diff
PR30384 fix. (1.38 KB, patch)
2007-07-05 00:05 UTC, Lennert Buytenhek
no flags Details | Diff
PR24998 fix. (670 bytes, patch)
2007-07-05 00:06 UTC, Lennert Buytenhek
no flags Details | Diff
ARM support for libgcc_post_upgrade.c. (1.27 KB, patch)
2007-07-05 00:07 UTC, Lennert Buytenhek
no flags Details | Diff
_uleb128_t wasn't defined in gcc 4.1 (366 bytes, patch)
2007-10-29 12:52 UTC, Andrew Haley
no flags Details | Diff
libtool has changed on trunk. This means that we have a slightly different path in this version. (1.11 KB, patch)
2007-10-30 16:04 UTC, Andrew Haley
no flags Details | Diff
Allow dollars in identifiers for the test suite (3.01 KB, patch)
2007-11-07 14:58 UTC, Andrew Haley
no flags Details | Diff
Test results (2.59 KB, text/plain)
2007-11-07 17:24 UTC, Andrew Haley
no flags Details

Description Lennert Buytenhek 2007-07-05 00:01:50 UTC
The attached patches add support for building gcc on the arm
architecture to the current rawhide gcc package.  There are three
issues which are addressed by this patch set:

1. Due to a different unwinder implementation, the current upstream
   ARM EABI gcc port does not support building libobjc or libjava.
   The current rawhide gcc spec file does support building without
   java, but it does not support building without objc.  Attached
   a patch which adds this, patterned after %{build_java}.

2. To successfully bootstrap on the ARM platform, a couple of PR
   fixes are necessary.  Attached are backports of fixes for PRs
   24998, 28516, and 30384.

3. Current libgcc-post-upgrade doesn't support ARM.  Attached a
   patch which adds this support.

These patches allow a successful build of the current rawhide gcc
package.  Please consider applying them.

Thanks for your time.

Comment 1 Lennert Buytenhek 2007-07-05 00:01:50 UTC
Created attachment 158560 [details]
Make building objc conditional.

Comment 2 Lennert Buytenhek 2007-07-05 00:04:42 UTC
Created attachment 158561 [details]
Spec file diffs for ARM.

(The PR28516 fix bumps the binutils requirement up to

Comment 3 Lennert Buytenhek 2007-07-05 00:05:23 UTC
Created attachment 158562 [details]
PR28516 fix.

Comment 4 Lennert Buytenhek 2007-07-05 00:05:52 UTC
Created attachment 158563 [details]
PR30384 fix.

Comment 5 Lennert Buytenhek 2007-07-05 00:06:27 UTC
Created attachment 158564 [details]
PR24998 fix.

Comment 6 Lennert Buytenhek 2007-07-05 00:07:18 UTC
Created attachment 158565 [details]
ARM support for libgcc_post_upgrade.c.

Comment 7 Jakub Jelinek 2007-07-18 14:38:14 UTC
The PRs are ok (though in each case I'd prefer to have corresponding ChangeLog
entry with the patch).  But disabling libobjc and libjava spec file changes
aren't acceptable, better just make it working.  Big part of Fedora depends
on libgcj, so leaving it out is a bad idea.  Current gcc's libjava is trunk
version, so making it work on arm benefits not just redhat branch, but also
the trunk.

Comment 8 Lennert Buytenhek 2007-07-21 21:50:19 UTC
This post by Daniel Jacobowitz explains the main issue with gcj and
friends on EABI ARM:

Andrew Haley is apparently looking into adding the necessary bits.  I'd
love to help out myself, but I'm not much of a gcc hacker. :-(

Could you please just add the bits that you find acceptable, and drop
the rest?  (Do you want me to re-submit the PRs with ChangeLog entries?)
I can of course easily maintain the objc/java disabling hacks separately
until this stuff gets fixed upstream.

Thanks again!

Comment 9 Jakub Jelinek 2007-09-06 15:35:27 UTC
Can you please try*.patch
patches and enable_java?

Comment 10 Jakub Jelinek 2007-09-19 16:41:40 UTC
You probably also need

Comment 11 Jakub Jelinek 2007-10-02 14:49:15 UTC

Comment 12 Lennert Buytenhek 2007-10-23 01:17:08 UTC
Negative -- and it doesn't help that every time I run into some or
another build failure, I get stuck not really knowing what to do next.

I'll try to put the build logs up somewhere.

Comment 13 Lennert Buytenhek 2007-10-23 22:16:06 UTC
A build of 4.1.2-33 plus your 6 patches plus rev 128250 bails out with:

   checking for exception model to use... configure: error: unable to detect
exception model

Full build logs are here:

Comment 14 Andrew Haley 2007-10-27 13:35:40 UTC
gcj on ARM EABI is fully functional on trunk.
What exactly is the status of the branch?

Jakub, have you applied the trunk changes to the Red Hat gcc branch?  Do you
want me to?

Comment 15 Andrew Haley 2007-10-28 09:10:45 UTC
Ah, I just rememberd something important.

On ARM eabi, you must *explicitly* configure with the exception model to use.

Like this:


This is because autoconf can't detect eabi.

Comment 16 Lennert Buytenhek 2007-10-28 23:15:13 UTC
> This is because autoconf can't detect eabi.

Do you mean because config.guess never reports -gnueabi ?

I've submitted this patch a couple of times to config-patches@, but
haven't had feedback yet:

Comment 17 Lennert Buytenhek 2007-10-29 09:17:37 UTC
A build of 4.1.2-33 plus Jakub's 6 patches plus rev 128250 and built with
--disable-sjlj-exceptions seems to get further, but bails out when it gets
to run

Comment 18 Andrew Haley 2007-10-29 10:13:03 UTC
I have no idea what the problem wit configure is, but I do know that even if you
specify arm-linux-gnueabi it still doesn't correctly default to using the
unwinder for exceptions.  You have to specify --disable-sjlj-exceptions explicitly.

Comment 19 Jakub Jelinek 2007-10-29 10:35:34 UTC
redhat/gcc-4_1-branch doesn't contain pregenerated *.class or *.h files for
libjava, so if you don't have a (1.5 capable) java, you need to do some more
steps.  You really need /usr/share/java/eclipse-ecj.jar, but that can be copied
over from any other arch.  Then one of:
1) build trunk gcc into some special prefix and replace after
mkdir java_hacks
in the *.spec file
the gij and gcj invocations with /tmp/gcc-trunk-install/..../gij and
2) or add the arm patches first to FC5-ish gcc.src.rpm, build that, install and
3) build F8ish gcc.src.rpm on some other arch where gcj is already supported
and pack the generated *.class and *.h files from the build for bootstrapping
purposes.  Then you can unpack them into the arm build tree

Comment 20 Andrew Haley 2007-10-29 12:52:27 UTC
Created attachment 241781 [details]
_uleb128_t wasn't defined in gcc 4.1

Comment 21 Andrew Haley 2007-10-30 16:04:19 UTC
Created attachment 243621 [details]
libtool has changed on trunk.  This means that we have a slightly different path in this version.

Comment 22 Andrew Haley 2007-10-30 16:07:53 UTC
With this patch libjava on arm builds.

However, we're not out of the woods yet.  If you try to run the interpeter, you
get an abort in libc.  Unfortunately, you can't tell where this abort is because
even with the debuginfo packages loaded, debuginfo for libc is broken:

Error while reading shared library symbols:
DW_FORM_strp used without .debug_str section [in module /lib/]
Error while reading shared library symbols:
DW_FORM_strp used without .debug_str section [in module /lib/]

I wonder if this might be a kernel problem, however.  If you single-step through
the code that allocates memory for closures, the program runs.  If you try to
run it without single-stepping, it aborts.

Comment 23 Andrew Haley 2007-11-07 14:58:02 UTC
Created attachment 250151 [details]
Allow dollars in identifiers for the test suite

Comment 24 Andrew Haley 2007-11-07 17:24:16 UTC
Created attachment 250521 [details]
Test results

Comment 25 Andrew Haley 2007-11-07 17:26:01 UTC
This is a good set of test results.  Don't worry about the jni.exp failures:
that's because some header files are missing from thet test suite.

Comment 26 Jakub Jelinek 2007-11-26 09:57:28 UTC
Please see gcc-4.1.2-34 in rawhide.  If I haven't screwed up, one should be
able to
rpmbuild -bc --with java_tar gcc41.spec
on i386, x86_64 or some other arch which already has libgcj, and then
rpmbuild -bb --with java_bootstrap gcc41.spec
on arm after you copy the i386/x86_64 generated tarball from .../SOURCES/
directory to arm .../SOURCES/ dir.  All the arm java patches I gathered are
there too and --disable-sjlj-exceptions, but untested on arm, so I'm interested
in feedback and any further changes that might be needed.

Comment 27 Bug Zapper 2008-04-04 12:54:52 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:

We will be following the process here: to ensure this
doesn't happen again.

Comment 28 Bug Zapper 2008-11-26 07:24:03 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:

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