Bug 246800

Summary: gcc: please add arm support
Product: [Fedora] Fedora Reporter: Lennert Buytenhek <buytenh>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: aph, triage
Target Milestone: ---   
Target Release: ---   
Hardware: arm9   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-26 06:19:20 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418    
Attachments:
Description Flags
Make building objc conditional.
none
Spec file diffs for ARM.
none
PR28516 fix.
none
PR30384 fix.
none
PR24998 fix.
none
ARM support for libgcc_post_upgrade.c.
none
_uleb128_t wasn't defined in gcc 4.1
none
libtool has changed on trunk. This means that we have a slightly different path in this version.
none
Allow dollars in identifiers for the test suite
none
Test results none

Description Lennert Buytenhek 2007-07-04 20:01:50 EDT
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-04 20:01:50 EDT
Created attachment 158560 [details]
Make building objc conditional.
Comment 2 Lennert Buytenhek 2007-07-04 20:04:42 EDT
Created attachment 158561 [details]
Spec file diffs for ARM.

(The PR28516 fix bumps the binutils requirement up to 2.17.50.0.5.)
Comment 3 Lennert Buytenhek 2007-07-04 20:05:23 EDT
Created attachment 158562 [details]
PR28516 fix.
Comment 4 Lennert Buytenhek 2007-07-04 20:05:52 EDT
Created attachment 158563 [details]
PR30384 fix.
Comment 5 Lennert Buytenhek 2007-07-04 20:06:27 EDT
Created attachment 158564 [details]
PR24998 fix.
Comment 6 Lennert Buytenhek 2007-07-04 20:07:18 EDT
Created attachment 158565 [details]
ARM support for libgcc_post_upgrade.c.
Comment 7 Jakub Jelinek 2007-07-18 10:38:14 EDT
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 17:50:19 EDT
This post by Daniel Jacobowitz explains the main issue with gcj and
friends on EABI ARM:

        http://lists.debian.org/debian-arm/2007/07/msg00042.html

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 11:35:27 EDT
Can you please try
http://people.redhat.com/jakub/gcc/gcc41-java-arm*.patch
patches and enable_java?
Thanks.
Comment 10 Jakub Jelinek 2007-09-19 12:41:40 EDT
Ping?
You probably also need
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128250
Comment 11 Jakub Jelinek 2007-10-02 10:49:15 EDT
Ping^2!
Comment 12 Lennert Buytenhek 2007-10-22 21:17:08 EDT
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 18:16:06 EDT
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:

   http://www.wantstofly.org/~buytenh/rh-gcc-java/
Comment 14 Andrew Haley 2007-10-27 09:35:40 EDT
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 05:10:45 EDT
Ah, I just rememberd something important.

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

Like this:

--disable-sjlj-exceptions

This is because autoconf can't detect eabi.

Comment 16 Lennert Buytenhek 2007-10-28 19:15:13 EDT
> 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:

http://www.wantstofly.org/~buytenh/config-guess-arm-fix.patch
Comment 17 Lennert Buytenhek 2007-10-29 05:17:37 EDT
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 check_jni_methods.sh:

  http://www.wantstofly.org/~buytenh/rh-gcc-java/buildlog.gcc.java3
Comment 18 Andrew Haley 2007-10-29 06:13:03 EDT
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 06:35:34 EDT
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
/tmp/gcc-trunk-install/..../gcj
2) or add the arm patches first to FC5-ish gcc.src.rpm, build that, install and
use
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 08:52:27 EDT
Created attachment 241781 [details]
_uleb128_t wasn't defined in gcc 4.1
Comment 21 Andrew Haley 2007-10-30 12:04:19 EDT
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 12:07:53 EDT
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/libm.so.6]
Error while reading shared library symbols:
DW_FORM_strp used without .debug_str section [in module /lib/libc.so.6]

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 09:58:02 EST
Created attachment 250151 [details]
Allow dollars in identifiers for the test suite
Comment 24 Andrew Haley 2007-11-07 12:24:16 EST
Created attachment 250521 [details]
Test results
Comment 25 Andrew Haley 2007-11-07 12:26:01 EST
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 04:57:28 EST
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 08:54:52 EDT
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
rawhide.
(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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 28 Bug Zapper 2008-11-26 02:24:03 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping