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.
Created attachment 158560 [details] Make building objc conditional.
Created attachment 158561 [details] Spec file diffs for ARM. (The PR28516 fix bumps the binutils requirement up to 2.17.50.0.5.)
Created attachment 158562 [details] PR28516 fix.
Created attachment 158563 [details] PR30384 fix.
Created attachment 158564 [details] PR24998 fix.
Created attachment 158565 [details] ARM support for libgcc_post_upgrade.c.
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.
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!
Can you please try http://people.redhat.com/jakub/gcc/gcc41-java-arm*.patch patches and enable_java? Thanks.
Ping? You probably also need http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128250
Ping^2!
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.
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/
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?
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.
> 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
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
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.
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
Created attachment 241781 [details] _uleb128_t wasn't defined in gcc 4.1
Created attachment 243621 [details] libtool has changed on trunk. This means that we have a slightly different path in this version.
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.
Created attachment 250151 [details] Allow dollars in identifiers for the test suite
Created attachment 250521 [details] Test results
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.
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.
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.
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