We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
A new root file system compose is available for download – http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta3-2011-05...
The latest repository – http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/o...
We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list – arm@lists.fedoraproject.org.
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
Gordan
Gordan Bobic gordan@bobich.net writes:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
Or we can just ignore it for F13 and worry about it for F14/15. Considering that F13 is almost EOLed upstream I'd rather see a less-complete F13 release and more work getting up-to-date with F14, F15, and updates.
Gordan
-derek
Derek Atkins wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
Or we can just ignore it for F13 and worry about it for F14/15. Considering that F13 is almost EOLed upstream I'd rather see a less-complete F13 release and more work getting up-to-date with F14, F15, and updates.
Sadly, the later src.rpms also fail to build properly. IIRC, most fail after about an hour. F15 actually does pretty well, it fails after 3 and a bit days, so that's the one I'm hoping to put some effort into fixing. But the later src.rpms get worse again. If we can get it working at all on F13, it will make getting the later versions working at least more tractable since hopefully the problems will be the same, or at least similar.
Gordan
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
Andrew.
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Dennis
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
Dennis
On 05/16/2011 03:04 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
I'm seeing this:
jar-core: [exec] Execute failed: java.io.IOException: java.io.IOException: Permission denied /var/tmp/rpm-tmp.Ax8TkV: line 58: 15587 Segmentation fault ant -Dbuild.sysclasspath=first -Djavacc.home=/usr/bin/javacc -Djavacc.jar=/usr/share/java/javacc.jar -Djavacc.jar.dir=/usr/share/java -Djavadoc.link=/usr/share/javadoc/java -Dversion=2.4.1 package RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Child returncode was: 1
Andrew Haley wrote:
On 05/16/2011 03:04 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote: > We are pleased to announce the release of Fedora 13 ARM Beta3. This > release includes additional software not found in Beta2, most notably > Abiword for your word processing needs. Unfortunately at this time we > are not able to offer OpenOffice due to some issues with java packages > ( java experts we could use your help! ). Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
I'm seeing this:
jar-core: [exec] Execute failed: java.io.IOException: java.io.IOException: Permission denied /var/tmp/rpm-tmp.Ax8TkV: line 58: 15587 Segmentation fault ant -Dbuild.sysclasspath=first -Djavacc.home=/usr/bin/javacc -Djavacc.jar=/usr/share/java/javacc.jar -Djavacc.jar.dir=/usr/share/java -Djavadoc.link=/usr/share/javadoc/java -Dversion=2.4.1 package RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Child returncode was: 1
I'm sure this is a silly question, but you don't have /var/tmp mounted with noexec perchance?
Gordan
On 05/16/2011 03:17 PM, Gordan Bobic wrote:
Andrew Haley wrote:
On 05/16/2011 03:04 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote: > Paul Whalen wrote: >> We are pleased to announce the release of Fedora 13 ARM Beta3. This >> release includes additional software not found in Beta2, most notably >> Abiword for your word processing needs. Unfortunately at this time we >> are not able to offer OpenOffice due to some issues with java packages >> ( java experts we could use your help! ). > Considering that Java only accounts for a small amount of seldom used > functionality, I would suggest that building LibreOffice --without-java > is probably the way forward for the foreseeable future. I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
I'm seeing this:
jar-core: [exec] Execute failed: java.io.IOException: java.io.IOException: Permission denied /var/tmp/rpm-tmp.Ax8TkV: line 58: 15587 Segmentation fault ant -Dbuild.sysclasspath=first -Djavacc.home=/usr/bin/javacc -Djavacc.jar=/usr/share/java/javacc.jar -Djavacc.jar.dir=/usr/share/java -Djavadoc.link=/usr/share/javadoc/java -Dversion=2.4.1 package RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Bad exit status from /var/tmp/rpm-tmp.Ax8TkV (%build) Child returncode was: 1
I'm sure this is a silly question, but you don't have /var/tmp mounted with noexec perchance?
This was from koji.
Andrew.
I'm really stuck without debuginfo, and
Could not find debuginfo for main pkg: java-1.5.0-gcj-devel-1.5.0.0-31.fc13.armv5tel
Is it available somewhere? It isn't at
http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/d...
Andrew.
On 05/16/2011 05:30 PM, Andrew Haley wrote:
I'm really stuck without debuginfo, and
Could not find debuginfo for main pkg: java-1.5.0-gcj-devel-1.5.0.0-31.fc13.armv5tel
Is it available somewhere? It isn't at
http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm/d...
Ah, forget that. It doesn't exist in any fedora port. :-)
Andrew.
On 05/16/2011 03:47 PM, Andrew Haley wrote:
On 05/16/2011 03:17 PM, Gordan Bobic wrote:
Andrew Haley wrote:
On 05/16/2011 03:04 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote: > On 05/12/2011 04:57 PM, Gordan Bobic wrote: >> Paul Whalen wrote: >>> We are pleased to announce the release of Fedora 13 ARM Beta3. This >>> release includes additional software not found in Beta2, most notably >>> Abiword for your word processing needs. Unfortunately at this time we >>> are not able to offer OpenOffice due to some issues with java packages >>> ( java experts we could use your help! ). >> Considering that Java only accounts for a small amount of seldom used >> functionality, I would suggest that building LibreOffice --without-java >> is probably the way forward for the foreseeable future. > I hope not. I'm now trying to get a Fedora/ARM system working and > I'll start fixing Java-related bugs. Please let me know which are > the most important. an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
I have found the cause of this. It's a gcc bug: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_s.so should be a linker script that contains
/* GNU ld script Use the shared library, but some functions are only in the static library. */ GROUP ( libgcc_s.so.1 libgcc.a )
but it's a symbolic link to /lib/libgcc_s.so.1 . This causes all gcj packages to fail to link.
I don't know why this has happened. I am building the gcc package to try to discover what went wrong.
Andrew.
On 05/16/2011 03:11 PM, Andrew Haley wrote:
On 05/16/2011 03:04 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:43:17 AM Andrew Haley wrote:
On 05/16/2011 02:41 PM, Dennis Gilmore wrote:
On Monday, May 16, 2011 08:37:43 AM Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote: > We are pleased to announce the release of Fedora 13 ARM Beta3. This > release includes additional software not found in Beta2, most notably > Abiword for your word processing needs. Unfortunately at this time we > are not able to offer OpenOffice due to some issues with java packages > ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
an updated openjdk would be a good start :)
Sure. What is the problem here? It just doesn't build?
Andrew.
looks like lucene is missing.
lucene failed to build http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=93642 there seems to be an issue with aot compiling the rpms. getting an unresolved symbol after successfully building things.
I have found two fatal bugs.
The first one is that /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/libgcc_s.so should be a linker script: instead it's a symlink. This caused most gcj-compiled packages to fail to link. I have a fixed gcc RPM.
The linker script should look like this:
/* GNU ld script Use the shared library, but some functions are only in the static library. */ GROUP ( /lib/libgcc_s.so.1 libgcc.a )
Secondly, locks do not work at all in gcj. This means that any program using more than one thread will eventually crash.
Fixed by this patch:
http://gcc.gnu.org/ml/java-patches/2009-q3/msg00069.html
(It's only the change to sysdep/arm/locks.h that we need.)
Andrew.
On 06/08/2011 06:08 PM, Andrew Haley wrote:
And this gem in the garbage collector:
/* SWP on ARM is very similar to XCHG on x86. Doesn't lock the * bus because there are no SMP ARM machines. If/when there are, * this code will likely need to be updated. */
:-)
Andrew.
I've found and fixed the bugs that were stopping gcj from working.
Firstly, there was the "libgcc is a symlink instead of a linker script" bug that I've explained before.
Then there was the libgcj/sysdep/arm/locks.h problem that broke locking. I already described that.
Then I found a locking bug in the boehm garbage collector. GC_clear(), which releases a lock, was simply
inline static void GC_clear(volatile unsigned int *addr) { /* Try to discourage gcc from moving anything past this. */ __asm__ __volatile__(" " : : : "memory"); *(addr) = 0; }
but it needs a memory barrier instruction. The easiest way to fix this is to use a gcc builtin that generates the correct barrier:
inline static void GC_clear(volatile unsigned int *addr) { __sync_lock_release(addr); }
I also replaced GC_test_and_set() with a gcc builtin, although this isn't strictly necessary:
inline static int GC_test_and_set(volatile unsigned int *addr) { return __sync_lock_test_and_set(addr, 1); }
There was also a problem in libffi when generating a closure. The code that generates a trampoline looks like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); \ })
Here, three instructions are laid down in memory, followed by some data fields. Once that has been done, __clear_cache() is called on the block of memory. Unfortunately, due to the requirement to placate SELinux, the same block of memory is mapped twice, once with RW mapping and once with RX mapping. Therefore, there must be two calls to __clear_cache(), one to flush the dcache, and one to flush the icache. Like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ unsigned char *insns = (unsigned char *)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); /* Clear data mapping. */ \ __clear_cache(insns, insns + 3 * sizeof (unsigned int)); \ /* Clear instruction \ mapping. */ \ })
Finally, libjava was segfaulting when an array class was finalized. This has apparently always happened, but on other platforms the segfault is caught and turned into a NullPointerException. All finalizers are called from an exception region that traps all exceptions and continues, so we never noticed.
Fixed thusly:
--- libjava/java/lang/natClass.cc 2010-06-11 05:09:01.000000000 -0400 +++ prev/libjava/java/lang/natClass.cc 2011-06-21 06:09:22.000000000 -0400 @@ -668,6 +668,8 @@ void java::lang::Class::finalize (void) { + // Array classes don't have an engine, and don't need to be finalized. + if (engine) engine->unregister(this); }
After all this, gcj now seems to work. I'm now building OpenJDK.
Andrew.
Hi Andrew,
Good news.
Have these issues been filed as bugs? Are there going to be fixes committed to mainline Fedora?
Peter
On Wed, Jun 22, 2011 at 6:20 PM, Andrew Haley aph@redhat.com wrote:
I've found and fixed the bugs that were stopping gcj from working.
Firstly, there was the "libgcc is a symlink instead of a linker script" bug that I've explained before.
Then there was the libgcj/sysdep/arm/locks.h problem that broke locking. I already described that.
Then I found a locking bug in the boehm garbage collector. GC_clear(), which releases a lock, was simply
inline static void GC_clear(volatile unsigned int *addr) { /* Try to discourage gcc from moving anything past this. */ __asm__ __volatile__(" " : : : "memory"); *(addr) = 0; }but it needs a memory barrier instruction. The easiest way to fix this is to use a gcc builtin that generates the correct barrier:
inline static void GC_clear(volatile unsigned int *addr) { __sync_lock_release(addr); }I also replaced GC_test_and_set() with a gcc builtin, although this isn't strictly necessary:
inline static int GC_test_and_set(volatile unsigned int *addr) { return __sync_lock_test_and_set(addr, 1); }There was also a problem in libffi when generating a closure. The code that generates a trampoline looks like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); \ })
Here, three instructions are laid down in memory, followed by some data fields. Once that has been done, __clear_cache() is called on the block of memory. Unfortunately, due to the requirement to placate SELinux, the same block of memory is mapped twice, once with RW mapping and once with RX mapping. Therefore, there must be two calls to __clear_cache(), one to flush the dcache, and one to flush the icache. Like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ unsigned char *insns = (unsigned char *)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); /* Clear data mapping. */ \ __clear_cache(insns, insns + 3 * sizeof (unsigned int)); \ /* Clear instruction \ mapping. */ \ })
Finally, libjava was segfaulting when an array class was finalized. This has apparently always happened, but on other platforms the segfault is caught and turned into a NullPointerException. All finalizers are called from an exception region that traps all exceptions and continues, so we never noticed.
Fixed thusly:
--- libjava/java/lang/natClass.cc 2010-06-11 05:09:01.000000000 -0400 +++ prev/libjava/java/lang/natClass.cc 2011-06-21 06:09:22.000000000 -0400 @@ -668,6 +668,8 @@ void java::lang::Class::finalize (void) {
- // Array classes don't have an engine, and don't need to be finalized.
- if (engine) engine->unregister(this);
}
After all this, gcj now seems to work. I'm now building OpenJDK.
Andrew. _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 22/06/11 21:15, Peter Robinson wrote:
Have these issues been filed as bugs?
I'm going to push all of them upstream.
Are there going to be fixes committed to mainline Fedora?
Is it even possible to push them to Fedora? F13 is EOL. If there's a way to get them into the F13 ARM repo I'd like to do that.
Andrew.
On Thu, Jun 23, 2011 at 8:01 AM, Andrew Haley aph@redhat.com wrote:
On 22/06/11 21:15, Peter Robinson wrote:
Have these issues been filed as bugs?
I'm going to push all of them upstream.
Are there going to be fixes committed to mainline Fedora?
Is it even possible to push them to Fedora? F13 is EOL. If there's a way to get them into the F13 ARM repo I'd like to do that.
Likely not F-13 but its not the only part of Fedora :-) although ctyler/PaulW can comment better on their plans for F-13.
I was meaning more into rawhide/F-15/F14. Rawhide so we don't have to go through this all again, and F-15/F-14 as they are the next for ARM. EG its the perfect time to be looking to get this into F-14 as we're building it for ARM now. In coming month or so we'll be kicking of F-15 and rawhide likely both for both hardfp and softfp targets.
Most of the stuff for F-14 currently I'm having committed upstream and then pulling the fixed builds for F-14 so that would be the way to go for the 2 current and for rawhide.
Peter
On 06/23/2011 09:10 AM, Peter Robinson wrote:
On Thu, Jun 23, 2011 at 8:01 AM, Andrew Haley aph@redhat.com wrote:
On 22/06/11 21:15, Peter Robinson wrote:
Have these issues been filed as bugs?
I'm going to push all of them upstream.
Are there going to be fixes committed to mainline Fedora?
Is it even possible to push them to Fedora? F13 is EOL. If there's a way to get them into the F13 ARM repo I'd like to do that.
Likely not F-13 but its not the only part of Fedora :-) although ctyler/PaulW can comment better on their plans for F-13.
I was meaning more into rawhide/F-15/F14.
Oh yes, definitely. I want gcj and OpenJDK to work properly on those architectures, and I'll be working on F15 as soon as it's stable enough to build on.
Andrew.
One other bug that breaks OpenJDK is fixed in libffi upstream:
The unconditional #define of ARM in /usr/lib/libffi-3.0.9/include/ffi.h breaks the OpenJDK build. It was fixed by the patch I've appended.
This fix doesn't seem to be in the libffi package in F14. I don't know if it's fixed in F15.
Andrew.
2010-07-07 Dan Horák dan@danny.cz
* include/ffi.h.in: Protect #define with #ifndef. * src/powerpc/ffitarget.h: Ditto. * src/s390/ffitarget.h: Ditto. * src/sparc/ffitarget.h: Ditto.
Index: include/ffi.h.in =================================================================== --- include/ffi.h.in (revision 162944) +++ include/ffi.h.in (revision 162945) @@ -57,7 +57,9 @@ #endif
/* Specify which architecture libffi is configured for. */ +#ifndef @TARGET@ #define @TARGET@ +#endif
/* ---- System configuration information --------------------------------- */
Index: src/powerpc/ffitarget.h =================================================================== --- src/powerpc/ffitarget.h (revision 162944) +++ src/powerpc/ffitarget.h (revision 162945) @@ -31,12 +31,18 @@ /* ---- System specific configurations ----------------------------------- */
#if defined (POWERPC) && defined (__powerpc64__) /* linux64 */ +#ifndef POWERPC64 #define POWERPC64 +#endif #elif defined (POWERPC_DARWIN) && defined (__ppc64__) /* Darwin */ +#ifndef POWERPC64 #define POWERPC64 +#endif #elif defined (POWERPC_AIX) && defined (__64BIT__) /* AIX64 */ +#ifndef POWERPC64 #define POWERPC64 #endif +#endif
#ifndef LIBFFI_ASM typedef unsigned long ffi_arg; Index: src/s390/ffitarget.h =================================================================== --- src/s390/ffitarget.h (revision 162944) +++ src/s390/ffitarget.h (revision 162945) @@ -28,8 +28,10 @@ #define LIBFFI_TARGET_H
#if defined (__s390x__) +#ifndef S390X #define S390X #endif +#endif
/* ---- System specific configurations ----------------------------------- */
Index: src/sparc/ffitarget.h =================================================================== --- src/sparc/ffitarget.h (revision 162944) +++ src/sparc/ffitarget.h (revision 162945) @@ -30,8 +30,10 @@ /* ---- System specific configurations ----------------------------------- */
#if defined(__arch64__) || defined(__sparcv9) +#ifndef SPARC64 #define SPARC64 #endif +#endif
#ifndef LIBFFI_ASM typedef unsigned long ffi_arg;
Andrew Haley píše v Čt 23. 06. 2011 v 09:43 +0100:
One other bug that breaks OpenJDK is fixed in libffi upstream:
The unconditional #define of ARM in /usr/lib/libffi-3.0.9/include/ffi.h breaks the OpenJDK build. It was fixed by the patch I've appended.
This fix doesn't seem to be in the libffi package in F14. I don't know if it's fixed in F15.
It's not fixed in the package yet as I expected Anthony will release new upstream version soon after the patch was merged upstream. But as I see it makes sense to update the package now. I can do it.
Dan
On Thu, Jun 23, 2011 at 9:53 AM, Dan Horák dan@danny.cz wrote:
Andrew Haley píše v Čt 23. 06. 2011 v 09:43 +0100:
One other bug that breaks OpenJDK is fixed in libffi upstream:
The unconditional #define of ARM in /usr/lib/libffi-3.0.9/include/ffi.h breaks the OpenJDK build. It was fixed by the patch I've appended.
This fix doesn't seem to be in the libffi package in F14. I don't know if it's fixed in F15.
It's not fixed in the package yet as I expected Anthony will release new upstream version soon after the patch was merged upstream. But as I see it makes sense to update the package now. I can do it.
Awesome! Can you make sure we get F-14 done as well and let me know the builds so I can make note of them (I'm trying to track ARM changes for F-14/15 to make like easier when we build it all - I will put it somewhere public soon).
Peter
Peter Robinson píše v Čt 23. 06. 2011 v 10:05 +0100:
On Thu, Jun 23, 2011 at 9:53 AM, Dan Horák dan@danny.cz wrote: Andrew Haley píše v Čt 23. 06. 2011 v 09:43 +0100: > One other bug that breaks OpenJDK is fixed in libffi upstream: > > The unconditional #define of ARM in /usr/lib/libffi-3.0.9/include/ffi.h > breaks the OpenJDK build. It was fixed by the patch I've appended. > > This fix doesn't seem to be in the libffi package in F14. I don't > know if it's fixed in F15.
It's not fixed in the package yet as I expected Anthony will release new upstream version soon after the patch was merged upstream. But as I see it makes sense to update the package now. I can do it.Awesome! Can you make sure we get F-14 done as well and let me know the builds so I can make note of them (I'm trying to track ARM changes for F-14/15 to make like easier when we build it all - I will put it somewhere public soon).
fixes committed to F-14, F-15 and master, built from master in primary Fedora
Dan
On 06/22/2011 06:20 PM, Andrew Haley wrote:
I've found and fixed the bugs that were stopping gcj from working.
This is really impressive. Thanks for describing the details!
Cheers, Niels
Firstly, there was the "libgcc is a symlink instead of a linker script" bug that I've explained before.
Then there was the libgcj/sysdep/arm/locks.h problem that broke locking. I already described that.
Then I found a locking bug in the boehm garbage collector. GC_clear(), which releases a lock, was simply
inline static void GC_clear(volatile unsigned int *addr) { /* Try to discourage gcc from moving anything past this. */ __asm__ __volatile__(" " : : : "memory"); *(addr) = 0; }but it needs a memory barrier instruction. The easiest way to fix this is to use a gcc builtin that generates the correct barrier:
inline static void GC_clear(volatile unsigned int *addr) { __sync_lock_release(addr);}
I also replaced GC_test_and_set() with a gcc builtin, although this isn't strictly necessary:
inline static int GC_test_and_set(volatile unsigned int *addr) { return __sync_lock_test_and_set(addr, 1); }There was also a problem in libffi when generating a closure. The code that generates a trampoline looks like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); \ })
Here, three instructions are laid down in memory, followed by some data fields. Once that has been done, __clear_cache() is called on the block of memory. Unfortunately, due to the requirement to placate SELinux, the same block of memory is mapped twice, once with RW mapping and once with RX mapping. Therefore, there must be two calls to __clear_cache(), one to flush the dcache, and one to flush the icache. Like this:
#define FFI_INIT_TRAMPOLINE(TRAMP,FUN,CTX) \ ({ unsigned char *__tramp = (unsigned char*)(TRAMP); \ unsigned int __fun = (unsigned int)(FUN); \ unsigned int __ctx = (unsigned int)(CTX); \ unsigned char *insns = (unsigned char *)(CTX); \ *(unsigned int*) &__tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \ *(unsigned int*) &__tramp[4] = 0xe59f0000; /* ldr r0, [pc] */ \ *(unsigned int*) &__tramp[8] = 0xe59ff000; /* ldr pc, [pc] */ \ *(unsigned int*) &__tramp[12] = __ctx; \ *(unsigned int*) &__tramp[16] = __fun; \ __clear_cache((&__tramp[0]), (&__tramp[19])); /* Clear data mapping. */ \ __clear_cache(insns, insns + 3 * sizeof (unsigned int)); \ /* Clear instruction \ mapping. */ \ })
Finally, libjava was segfaulting when an array class was finalized. This has apparently always happened, but on other platforms the segfault is caught and turned into a NullPointerException. All finalizers are called from an exception region that traps all exceptions and continues, so we never noticed.
Fixed thusly:
--- libjava/java/lang/natClass.cc 2010-06-11 05:09:01.000000000 -0400 +++ prev/libjava/java/lang/natClass.cc 2011-06-21 06:09:22.000000000 -0400 @@ -668,6 +668,8 @@ void java::lang::Class::finalize (void) {
- // Array classes don't have an engine, and don't need to be finalized.
- if (engine) engine->unregister(this);
}
After all this, gcj now seems to work. I'm now building OpenJDK.
Andrew. _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 16/05/11 14:37, Andrew Haley wrote:
On 05/12/2011 04:57 PM, Gordan Bobic wrote:
Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future.
I hope not. I'm now trying to get a Fedora/ARM system working and I'll start fixing Java-related bugs. Please let me know which are the most important.
Progress report: I have the system installed, and I'm looking at bugs in the ecj package, and possibly in gcc itself.
One thing: the whole system does not seem to be very stable. gdb doesn't work at all well, which makes debugging hard. It really doesn't feel like a system that's ready for Beta.
Andrew.
On 2011-05-12 10:35, Paul Whalen wrote:
We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list � arm@lists.fedoraproject.org.
I'm new to the Fedora ARM world; my PandaBoard just arrived a couple weeks ago and I soon had Fedora 13 Beta 2 running on it.
Overall, the userspace in F13 Beta 2 has been great, and I'll be updating to Beta 3 right away! Thanks for the hard work!
However, I found the process rather confusing with respect to the kernel. The root filesystem was pretty straightforward, but it wasn't clear to me where I was supposed to get a kernel from. Should I be building my own? Or is there a repository out there with ARM kernels? Some kernels support running a GUI but are short on RAM, others maximize the RAM but are limited to serial consoles. Which one should I use?
After a lot of reading [1][2][3][4][5], I ended up using the kernel at http://scotland.proximity.on.ca/arm/kernel/pandaboard/
This kernel doesn't appear to support SELinux or iptables, though, so I'm going to give David Marlin's kernel[6] a try next.
Out of curiosity, I tried Ubuntu 11.04 to compare and it was surprisingly easy to install: just dd the image to an SD card and boot. The image includes a kernel and the necessary partition layout, and it automatically resizes the root filesystem partition to fill up the SD card on first boot (which is slow, but that's the SD card's fault).
Thanks again! Jeff
[1] http://fedoraproject.org/wiki/Architectures/ARM/Using [2] http://pandaboard.org/content/resources/getting-started [3] http://omappedia.org/wiki/Main_Page [4] http://paulfedora.wordpress.com/ [5] http://perfectlylogical.wordpress.com/ [6] http://lists.fedoraproject.org/pipermail/arm/2011-May/001270.html
Jeffrey Bastian wrote:
On 2011-05-12 10:35, Paul Whalen wrote:
We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list � arm@lists.fedoraproject.org.
I'm new to the Fedora ARM world; my PandaBoard just arrived a couple weeks ago and I soon had Fedora 13 Beta 2 running on it.
Overall, the userspace in F13 Beta 2 has been great, and I'll be updating to Beta 3 right away! Thanks for the hard work!
However, I found the process rather confusing with respect to the kernel. The root filesystem was pretty straightforward, but it wasn't clear to me where I was supposed to get a kernel from. Should I be building my own? Or is there a repository out there with ARM kernels? Some kernels support running a GUI but are short on RAM, others maximize the RAM but are limited to serial consoles. Which one should I use?
After a lot of reading [1][2][3][4][5], I ended up using the kernel at http://scotland.proximity.on.ca/arm/kernel/pandaboard/
This kernel doesn't appear to support SELinux or iptables, though, so I'm going to give David Marlin's kernel[6] a try next.
I've build a newer version that has HIMEM enabled:
kernel-omap-2.6.38.5-24.02.fc13.armv7l.rpm http://people.redhat.com/dmarlin/packages/FedoraArm/RPMS/armv7l/kernel-omap-2.6.38.5-24.02.fc13.armv7l.rpm
so if you have 1GB memory, and are _not_ using TI's binary multimedia bits (which use RAM from 463 to 511MB) you can use the full amount of memory available on the Panda Board. When using the new build, omit the "mem=463M" in the bootargs.
Again, there has been very little testing on this kernel, so if you encounter any problems, or have suggestions for improvement, please post.
d.marlin ========
Out of curiosity, I tried Ubuntu 11.04 to compare and it was surprisingly easy to install: just dd the image to an SD card and boot. The image includes a kernel and the necessary partition layout, and it automatically resizes the root filesystem partition to fill up the SD card on first boot (which is slow, but that's the SD card's fault).
Thanks again! Jeff
[1] http://fedoraproject.org/wiki/Architectures/ARM/Using [2] http://pandaboard.org/content/resources/getting-started [3] http://omappedia.org/wiki/Main_Page [4] http://paulfedora.wordpress.com/ [5] http://perfectlylogical.wordpress.com/ [6] http://lists.fedoraproject.org/pipermail/arm/2011-May/001270.html _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Thursday, May 12, 2011 10:35:21 AM Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
A new root file system compose is available for download – http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta3-2011- 05-10.tar.bz2
The latest repository – http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm /os/
you can use mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... for the mirrors. the content has been synced to the primary secondary arch mirror and will go out to all the secondary arch mirrors as they sync
Dennis
We are again asking for feedback as we prepare for a final compose of Fedora 13 for ARM, and put all our efforts behind Fedora 14. Feedback can be forward to us via the mailing list – arm@lists.fedoraproject.org.
On 05/13/2011 10:03 PM, Dennis Gilmore wrote:
On Thursday, May 12, 2011 10:35:21 AM Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
A new root file system compose is available for download – http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta3-2011- 05-10.tar.bz2
The latest repository – http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/arm /os/
you can use mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... for the mirrors. the content has been synced to the primary secondary arch mirror and will go out to all the secondary arch mirrors as they sync
Surely that should be made to work with arch=armv5tel rather than just arch=arm ?
Gordan
On Friday, May 13, 2011 04:17:46 PM Gordan Bobic wrote:
On 05/13/2011 10:03 PM, Dennis Gilmore wrote:
On Thursday, May 12, 2011 10:35:21 AM Paul Whalen wrote:
We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ).
A new root file system compose is available for download – http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta3-201 1- 05-10.tar.bz2
The latest repository – http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-05-10/f13-arm/a rm /os/
you can use mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releas ever&arch=arm for the mirrors. the content has been synced to the primary secondary arch mirror and will go out to all the secondary arch mirrors as they sync
Surely that should be made to work with arch=armv5tel rather than just arch=arm ?
no, the basearch for arm arches is arm there is a bug in yum thats causing the basearch to evaluate to armv5tel not arm. which means you cant have some packages optimised for say armv6l or armv7l while the base is armv5tel. Im going to look at making sure arm works right. maybe its already done and the yum is too old.
Dennis
-
Andrew Haley -
d.marlin -
Dan Horák -
Dennis Gilmore -
Derek Atkins -
Gordan Bobic -
Jeffrey Bastian -
Niels de Vos -
Paul Whalen -
Peter Robinson