[opensuse-arm] ARM status
Hi guys, It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :). *** We can successfully build ~3500 out of ~4700 Factory packages! *** Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :). Also, there are a couple of things we have now that weren't there before: * Lots of qemu fixes to get stuff building * Kernel rpms so we can generate kernels for the following flavors: default, tegra, omap2plus (Pandaboard), imx51 (EFIKA MX) * Build fixes for a number of packages (otherwise we wouldn't get 3.5k!) * U-boot package for pandaboard (thanks Joop!) * Probably a lot of stuff I can't remember atm. If you have worked on something and want to add it to the list, please reply to this mail so we have more overview :). So what is still missing from here? Well, these are the pieces I'm tracking right now: * Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1] * Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :) [1] To handle exceptions we need to be able to unwind state at certain points in the code. This unwinding requires special tables which are different on ARM than on any other platform out there. Now the problem is that even a program as simple as: #include <stdio.h> int main(int argc, char **argv) { try { throw -1; } catch (int) { fprintf(stderr, "We caught an exception of type int\n"); } } fails to execute on our current builds. Thus gmp and gcj don't build properly and everything depending on Java just doesn't even get built. I'm trying to reproduce this with Linaro's gcc to maybe get some help from them. Once we have that, the kernel might end up working and we should have an almost-completely-built distro (no guarantees for actually working code). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.11.2011, at 16:53, Alexander Graf wrote:
Hi guys,
It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :).
*** We can successfully build ~3500 out of ~4700 Factory packages! ***
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).
Also, there are a couple of things we have now that weren't there before:
* Lots of qemu fixes to get stuff building * Kernel rpms so we can generate kernels for the following flavors: default, tegra, omap2plus (Pandaboard), imx51 (EFIKA MX) * Build fixes for a number of packages (otherwise we wouldn't get 3.5k!) * U-boot package for pandaboard (thanks Joop!) * Probably a lot of stuff I can't remember atm. If you have worked on something and want to add it to the list, please reply to this mail so we have more overview :).
So what is still missing from here? Well, these are the pieces I'm tracking right now:
* Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1] * Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :)
[1] To handle exceptions we need to be able to unwind state at certain points in the code. This unwinding requires special tables which are different on ARM than on any other platform out there. Now the problem is that even a program as simple as:
#include <stdio.h>
int main(int argc, char **argv) { try { throw -1; }
catch (int) { fprintf(stderr, "We caught an exception of type int\n"); } }
fails to execute on our current builds. Thus gmp and gcj don't build properly and everything depending on Java just doesn't even get built. I'm trying to reproduce this with Linaro's gcc to maybe get some help from them. Once we have that, the kernel might end up working and we should have an almost-completely-built distro (no guarantees for actually working code).
Update: It works with Linaro's g++. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.11.2011, at 16:56, Alexander Graf <agraf@suse.de> wrote:
On 24.11.2011, at 16:53, Alexander Graf wrote:
Hi guys,
It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :).
*** We can successfully build ~3500 out of ~4700 Factory packages! ***
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).
Also, there are a couple of things we have now that weren't there before:
* Lots of qemu fixes to get stuff building * Kernel rpms so we can generate kernels for the following flavors: default, tegra, omap2plus (Pandaboard), imx51 (EFIKA MX) * Build fixes for a number of packages (otherwise we wouldn't get 3.5k!) * U-boot package for pandaboard (thanks Joop!) * Probably a lot of stuff I can't remember atm. If you have worked on something and want to add it to the list, please reply to this mail so we have more overview :).
So what is still missing from here? Well, these are the pieces I'm tracking right now:
* Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1] * Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :)
[1] To handle exceptions we need to be able to unwind state at certain points in the code. This unwinding requires special tables which are different on ARM than on any other platform out there. Now the problem is that even a program as simple as:
#include <stdio.h>
int main(int argc, char **argv) { try { throw -1; }
catch (int) { fprintf(stderr, "We caught an exception of type int\n"); } }
fails to execute on our current builds. Thus gmp and gcj don't build properly and everything depending on Java just doesn't even get built. I'm trying to reproduce this with Linaro's gcc to maybe get some help from them. Once we have that, the kernel might end up working and we should have an almost-completely-built distro (no guarantees for actually working code).
Update: It works with Linaro's g++.
I have good and bad news here :). I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing. However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly! So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing... Alex
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thu, 2011-11-24 at 19:45 +0100, Alexander Graf wrote:
I have good and bad news here :).
I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing.
However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly!
So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing...
Have you tried reproducing it on one of the Efikas? What are the differences between our gcc and that of Linaro's, if that is indeed the cause? Regards, Andy -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.11.2011, at 20:49, Andrew Wafaa <awafaa@opensuse.org> wrote:
On Thu, 2011-11-24 at 19:45 +0100, Alexander Graf wrote:
I have good and bad news here :).
I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing.
However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly!
So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing...
Have you tried reproducing it on one of the Efikas?
For what purpose? It doesn't depend on the machine type.
What are the differences between our gcc and that of Linaro's, if that is indeed the cause?
The Linaro gcc behaves the same depending on the machine, so I'm fairly sure it's uninitialized memory. Alex
Regards,
Andy
-- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 24.11.2011, at 21:33, Alexander Graf wrote:
On 24.11.2011, at 20:49, Andrew Wafaa <awafaa@opensuse.org> wrote:
On Thu, 2011-11-24 at 19:45 +0100, Alexander Graf wrote:
I have good and bad news here :).
I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing.
However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly!
So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing...
Have you tried reproducing it on one of the Efikas?
For what purpose? It doesn't depend on the machine type.
What are the differences between our gcc and that of Linaro's, if that is indeed the cause?
The Linaro gcc behaves the same depending on the machine, so I'm fairly sure it's uninitialized memory.
Ok, so I debugged it down to gas which uses uninitialized memory in its unwind table generation: ==2009== Syscall param write(buf) points to uninitialised byte(s) ==2009== at 0x48EE56C: write (in /lib/libc-2.14.1.so) ==2009== by 0x48B51BB: _IO_file_write@@GLIBC_2.4 (fileops.c:1281) ==2009== by 0x48B510F: new_do_write (fileops.c:535) ==2009== by 0x48B5E1D: _IO_do_write@@GLIBC_2.4 (fileops.c:508) ==2009== by 0x48B6907: _IO_switch_to_get_mode (genops.c:189) ==2009== by 0x48B52D3: _IO_file_seekoff@@GLIBC_2.4 (fileops.c:991) ==2009== by 0x48AF0AB: _IO_seekoff_unlocked (ioseekoff.c:71) ==2009== by 0x48B4031: fseeko64 (fseeko64.c:42) ==2009== by 0x73A79: bfd_seek (bfdio.c:315) ==2009== by 0x5CB6F: _bfd_elf_write_object_contents (elf.c:5217) ==2009== by 0x4099F: bfd_close (opncls.c:701) ==2009== by 0x16E51: output_file_close (output-file.c:65) ==2009== Address 0x4d500d7 is not stack'd, malloc'd or (recently) free'd ==2009== Uninitialised value was created by a heap allocation ==2009== at 0x482F694: malloc (vg_replace_malloc.c:263) ==2009== by 0x7F353: xmalloc (xmalloc.c:147) ==2009== by 0x48BE1D7: _obstack_begin (obstack.c:186) ==2009== by 0x1C3E9: subseg_set_rest (subsegs.c:110) ==2009== by 0x1C50D: subseg_force_new (subsegs.c:195) ==2009== by 0x3B257: obj_elf_change_section (obj-elf.c:583) ==2009== by 0x25A47: start_unwind_section (tc-arm.c:19828) ==2009== by 0x3240D: create_unwind_entry (tc-arm.c:19857) ==2009== by 0x1B59D: read_a_source_file (read.c:919) ==2009== by 0xAEC1: main (as.c:1089) I sent a mail to the binutils ML and pushed a quick hacky fix (just always memset(0) xmalloc'ed memory) to openSUSE:Factory:ARM so we can actually build something. Let's hope this solves the exception and unwind mysteries! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 25. November 2011, 02:48:46 schrieb Alexander Graf: ...
I sent a mail to the binutils ML and pushed a quick hacky fix (just always memset(0) xmalloc'ed memory) to openSUSE:Factory:ARM so we can actually build something. Let's hope this solves the exception and unwind mysteries!
Very cool! That should really help a lot! I branched current kernel and u-boot* packages to :ARM, so that we also get the kernel stack and don't have to wait for final 3.2 kernel. bye adrian
Alex
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Fri, November 25, 2011 2:48 am, Alexander Graf wrote:
On 24.11.2011, at 21:33, Alexander Graf wrote:
On 24.11.2011, at 20:49, Andrew Wafaa <awafaa@opensuse.org> wrote:
On Thu, 2011-11-24 at 19:45 +0100, Alexander Graf wrote:
I have good and bad news here :).
I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing.
However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly!
So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing...
Have you tried reproducing it on one of the Efikas?
For what purpose? It doesn't depend on the machine type.
What are the differences between our gcc and that of Linaro's, if that is indeed the cause?
The Linaro gcc behaves the same depending on the machine, so I'm fairly sure it's uninitialized memory.
Ok, so I debugged it down to gas which uses uninitialized memory in its unwind table generation:
==2009== Syscall param write(buf) points to uninitialised byte(s) ==2009== at 0x48EE56C: write (in /lib/libc-2.14.1.so) ==2009== by 0x48B51BB: _IO_file_write@@GLIBC_2.4 (fileops.c:1281) ==2009== by 0x48B510F: new_do_write (fileops.c:535) ==2009== by 0x48B5E1D: _IO_do_write@@GLIBC_2.4 (fileops.c:508) ==2009== by 0x48B6907: _IO_switch_to_get_mode (genops.c:189) ==2009== by 0x48B52D3: _IO_file_seekoff@@GLIBC_2.4 (fileops.c:991) ==2009== by 0x48AF0AB: _IO_seekoff_unlocked (ioseekoff.c:71) ==2009== by 0x48B4031: fseeko64 (fseeko64.c:42) ==2009== by 0x73A79: bfd_seek (bfdio.c:315) ==2009== by 0x5CB6F: _bfd_elf_write_object_contents (elf.c:5217) ==2009== by 0x4099F: bfd_close (opncls.c:701) ==2009== by 0x16E51: output_file_close (output-file.c:65) ==2009== Address 0x4d500d7 is not stack'd, malloc'd or (recently) free'd ==2009== Uninitialised value was created by a heap allocation ==2009== at 0x482F694: malloc (vg_replace_malloc.c:263) ==2009== by 0x7F353: xmalloc (xmalloc.c:147) ==2009== by 0x48BE1D7: _obstack_begin (obstack.c:186) ==2009== by 0x1C3E9: subseg_set_rest (subsegs.c:110) ==2009== by 0x1C50D: subseg_force_new (subsegs.c:195) ==2009== by 0x3B257: obj_elf_change_section (obj-elf.c:583) ==2009== by 0x25A47: start_unwind_section (tc-arm.c:19828) ==2009== by 0x3240D: create_unwind_entry (tc-arm.c:19857) ==2009== by 0x1B59D: read_a_source_file (read.c:919) ==2009== by 0xAEC1: main (as.c:1089)
I sent a mail to the binutils ML and pushed a quick hacky fix (just always memset(0) xmalloc'ed memory) to openSUSE:Factory:ARM so we can actually build something. Let's hope this solves the exception and unwind mysteries!
I see that gmp has been build without any errors. :) Great job,
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote:
Hi guys,
It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :).
*** We can successfully build ~3500 out of ~4700 Factory packages! ***
I'm still not able to find, where is the right project with armv7l failing packages, could somebody send link? This one https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgname=&repo_armv5el=1&repo_armv7hl=1&repo_images=1&arch_armv5el=1&arch_armv7hl=1&arch_local=1&project=openSUSE%3AFactory%3AARM&defaults=0 (which can be found on http://en.opensuse.org/Portal:ARM) doesn't show any armv7l packages...
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).
If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have experience with this). I would just disable it when I'm trying to fix or test something.
So what is still missing from here? Well, these are the pieces I'm tracking right now:
* Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1]
I think/hope that I can help a bit here.
* Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :) And with this hopefully too.
Best regards, Tomas Cech Sleep_Walker
On 27.11.2011, at 20:17, Tomas Cech wrote:
On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote:
Hi guys,
It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :).
*** We can successfully build ~3500 out of ~4700 Factory packages! ***
I'm still not able to find, where is the right project with armv7l failing packages, could somebody send link?
This one https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgname=&repo_armv5el=1&repo_armv7hl=1&repo_images=1&arch_armv5el=1&arch_armv7hl=1&arch_local=1&project=openSUSE%3AFactory%3AARM&defaults=0 (which can be found on http://en.opensuse.org/Portal:ARM) doesn't show any armv7l packages...
Ah, sorry, I fixed the link on the wiki now :). Basically your portal to any interesting information is at https://build.opensuse.org/project/show?project=openSUSE:Factory:ARM
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).
If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have experience with this). I would just disable it when I'm trying to fix or test something.
Yes, please :). Adrian probably has a pretty clear idea on what's required to get this rolling.
So what is still missing from here? Well, these are the pieces I'm tracking right now:
* Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1]
I think/hope that I can help a bit here.
I got the pandaboard kernel reasonably well working now, so if you could tackle the i.MX51 one, I would very much appreciate it :).
* Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :) And with this hopefully too.
There are a couple of generic broken ones thanks to the recent ncurses changes in factory. I'm still puzzled why bash doesn't compile anymore for example - it's definitely related to the curses change. Then there are a number of packages that complain in thumb mode "swp" instructions. However, swp is not guaranteed by the armv7 architecture anymore, so if there's old thumb code somewhere which gets triggered by our build, you see those swp errors. The easy fix is to just disable thumb for that package. Just check texlive-bin on how that works :). Alex
On Sun, November 27, 2011 8:35 pm, Alexander Graf wrote:
On 27.11.2011, at 20:17, Tomas Cech wrote:
On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote:
Hi guys,
It's time for a small status update. This won't be an extensive list, but at least give you an overview of what has happened since the last time :).
*** We can successfully build ~3500 out of ~4700 Factory packages! ***
I'm still not able to find, where is the right project with armv7l failing packages, could somebody send link?
This one https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgname=&repo_armv5el=1&repo_armv7hl=1&repo_images=1&arch_armv5el=1&arch_armv7hl=1&arch_local=1&project=openSUSE%3AFactory%3AARM&defaults=0 (which can be found on http://en.opensuse.org/Portal:ARM) doesn't show any armv7l packages...
Ah, sorry, I fixed the link on the wiki now :). Basically your portal to any interesting information is at
https://build.opensuse.org/project/show?project=openSUSE:Factory:ARM
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).
If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have experience with this). I would just disable it when I'm trying to fix or test something.
Yes, please :). Adrian probably has a pretty clear idea on what's required to get this rolling.
So what is still missing from here? Well, these are the pieces I'm tracking right now:
* Kiwi support (Marcus is on it!) * Kernel testing and making-it-work [1]
I think/hope that I can help a bit here.
I got the pandaboard kernel reasonably well working now, so if you could tackle the i.MX51 one, I would very much appreciate it :).
* Exception handling [1] keeps us from building Java, keeps us from building most of the other 1200 packages * hwinfo probably needs some love for ARM * yast2 could use some love as well :) * X drivers are probably still missing * Fixing broken packages, there are still a few that are not broken because of exception handling :) And with this hopefully too.
There are a couple of generic broken ones thanks to the recent ncurses changes in factory. I'm still puzzled why bash doesn't compile anymore for example - it's definitely related to the curses change.
I assume this is the problem, see buildlog ( https://build.opensuse.org/package/rawlog?arch=armv7l&package=bash&project=openSUSE%3AFactory%3AARM&repository=standard ) : <qoute> checking version of installed readline library... configure: WARNING: Could not test version of installed readline library. configure: WARNING: installed readline library is too old to be linked with bash configure: WARNING: using private bash version </quote>
Then there are a number of packages that complain in thumb mode "swp" instructions. However, swp is not guaranteed by the armv7 architecture anymore, so if there's old thumb code somewhere which gets triggered by our build, you see those swp errors. The easy fix is to just disable thumb for that package. Just check texlive-bin on how that works :).
Alex
Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf:
On 27.11.2011, at 20:17, Tomas Cech wrote:
On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote:
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).>
We did a full rebuild which took quite some time plus plenty of Factory submissions. However, this morning there were only three packages building and non blocked. Since these three packages seem to be rather dead (being in some endless loop), I aborted their build job, so a new armv7l repo has been pushed out now. The packages which I aborted were: mono-core ksh gcc46-testsuite (Not sure if this was an endless loop)
If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have experience with this). I would just disable it when I'm trying to fix or test something.
Yes, please :). Adrian probably has a pretty clear idea on what's required to get this rolling.
They won't help the .opensuse.org build system, since we don't have a working xen or kvm working for arm yet. Check with me on internal channel how to involve them anyway in internal builds ;) Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 28.11.2011, at 11:06, Adrian Schröter wrote:
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf:
On 27.11.2011, at 20:17, Tomas Cech wrote:
On Thu, Nov 24, 2011 at 04:53:36PM +0100, Alexander Graf wrote:
Unfortunately Factory is updating so fast that we just haven't managed to do a full build of all these shina packages for the last 3 weeks, so packages you see in the download repository are from 3 weeks ago. To fetch the newer builds, just run "osc getbinaries ...". Beware of dragons though :).>
We did a full rebuild which took quite some time plus plenty of Factory submissions.
However, this morning there were only three packages building and non blocked. Since these three packages seem to be rather dead (being in some endless loop), I aborted their build job, so a new armv7l repo has been pushed out now.
The packages which I aborted were:
mono-core ksh gcc46-testsuite (Not sure if this was an endless loop)
If it is worth of effort, I can set up that new Efika MX as OBS worker (if someone help me - prusnak or miska probably already have experience with this). I would just disable it when I'm trying to fix or test something.
Yes, please :). Adrian probably has a pretty clear idea on what's required to get this rolling.
They won't help the .opensuse.org build system, since we don't have a working xen or kvm working for arm yet. Check with me on internal channel how to involve them anyway in internal builds ;)
Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ...
The problem is QEMU related. Building those packages on native hardware works. Could we maybe try and build them on real hw + inject them somehow for now so that we have _something_ to work with? I have to look at the QEMU breakage nevertheless but it's definitely not easy. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Montag, 28. November 2011, 10:11:21 schrieb Alexander Graf:
On 28.11.2011, at 11:06, Adrian Schröter wrote:
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf: ... Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ...
The problem is QEMU related. Building those packages on native hardware works. Could we maybe try and build them on real hw + inject them somehow for now so that we have _something_ to work with? I have to look at the QEMU breakage nevertheless but it's definitely not easy.
Yes, I could inject ecj-bootstrap from the non-qemu build, but so far this package has not yet compiled there either. When you have a manual build from somewhere I could of course use this one. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 28.11.2011, at 11:25, Adrian Schröter <adrian@suse.de> wrote:
Am Montag, 28. November 2011, 10:11:21 schrieb Alexander Graf:
On 28.11.2011, at 11:06, Adrian Schröter wrote:
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf: ... Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ...
The problem is QEMU related. Building those packages on native hardware works. Could we maybe try and build them on real hw + inject them somehow for now so that we have _something_ to work with? I have to look at the QEMU breakage nevertheless but it's definitely not easy.
Yes, I could inject ecj-bootstrap from the non-qemu build, but so far this package has not yet compiled there either.
When you have a manual build from somewhere I could of course use this one.
Well, I don't think just ecj-bootstrap will be enough. It looks like things break every time code gets JITed inside the guest - mono breaks the same way. I'll give it a try though and create an rpm. So far I've only executed the offending commands in the build chroot from native and emulated and saw them work on native hardware. We could try to at least generate ca-certificates on a real machine, inject that, and then move our way towards a working JeOS image. We could then deploy machines with that image and make them internal build hosts, hopefully speeding up the native build, giving us more rpms for otherwise broken packages. Eventually we'd have most packages around ;). It would be nice to have our emulated approach work well too though, so I'll try to see if I can reproduce the QEMU problem in full system emulation. Maybe I can get Linaro interested in fixing it that way ;). Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 28.11.2011, at 11:01, Alexander Graf wrote:
On 28.11.2011, at 11:25, Adrian Schröter <adrian@suse.de> wrote:
Am Montag, 28. November 2011, 10:11:21 schrieb Alexander Graf:
On 28.11.2011, at 11:06, Adrian Schröter wrote:
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf: ... Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ...
The problem is QEMU related. Building those packages on native hardware works. Could we maybe try and build them on real hw + inject them somehow for now so that we have _something_ to work with? I have to look at the QEMU breakage nevertheless but it's definitely not easy.
Yes, I could inject ecj-bootstrap from the non-qemu build, but so far this package has not yet compiled there either.
When you have a manual build from somewhere I could of course use this one.
Well, I don't think just ecj-bootstrap will be enough. It looks like things break every time code gets JITed inside the guest - mono breaks the same way. I'll give it a try though and create an rpm. So far I've only executed the offending commands in the build chroot from native and emulated and saw them work on native hardware.
After lots of blood and sweat I finally managed to track the issue down. It's our old friend, boehm-gc! Apparently boehm-gc wants to send signals between threads while setting SA_RESTART on that signal. Unfortunately, because QEMU passes this flag to the actual host signal handler description, we never get around to execute the signal if we're waiting in a syscall. The second thread is waiting for the signal handler to be run though, so we're in a classical deadlock. I managed to work around that with a few hacks here and there in QEMU and now managed to successfully build boehm-gc 7.1 (texlive-bin!) and ecj-bootstrap. The updated QEMU is already checked in and running on OBS. So once it OBS gets to the point where it wants to run Java code, we'll hopefully have something that actually works :). Keep your fingers crossed! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 2. Dezember 2011, 00:59:38 schrieb Alexander Graf:
Am Montag, 28. November 2011, 10:11:21 schrieb Alexander Graf:
On 28.11.2011, at 11:06, Adrian Schröter wrote:
Am Sonntag, 27. November 2011, 20:35:26 schrieb Alexander Graf: ...
Thanks to Alex, the crashes when using exceptions are gone. Also gcj is not directly crashing anymore when building ecj-bootstrap. Unfortunatly it just hangs in an endless loop now. So we still don't have a working java stack. This is the major reason for the last ~ 1000 unresolvable (aka unbuildable) packages. If someone could dig into that it would be great ...
The problem is QEMU related. Building those packages on native hardware works. Could we maybe try and build them on real hw + inject them somehow for now so that we have _something_ to work with? I have to look at the QEMU breakage nevertheless but it's definitely not easy.
Yes, I could inject ecj-bootstrap from the non-qemu build, but so far this package has not yet compiled there either.
When you have a manual build from somewhere I could of course use this one.> Well, I don't think just ecj-bootstrap will be enough. It looks like
On 28.11.2011, at 11:25, Adrian Schröter <adrian@suse.de> wrote: things break every time code gets JITed inside the guest - mono breaks the same way. I'll give it a try though and create an rpm. So far I've only executed the offending commands in the build chroot from native and emulated and saw them work on native hardware. After lots of blood and sweat I finally managed to track the issue down. It's our old friend, boehm-gc! Apparently boehm-gc wants to send signals between threads while setting SA_RESTART on that signal. Unfortunately, because QEMU passes this flag to the actual host signal handler description, we never get around to execute the signal if we're waiting in a syscall. The second thread is waiting for the signal handler to be run
On 28.11.2011, at 11:01, Alexander Graf wrote: though, so we're in a classical deadlock.
I managed to work around that with a few hacks here and there in QEMU and now managed to successfully build boehm-gc 7.1 (texlive-bin!) and ecj-bootstrap. The updated QEMU is already checked in and running on OBS. So once it OBS gets to the point where it wants to run Java code, we'll hopefully have something that actually works :).
Keep your fingers crossed!
Dear Grand-Master of qemu, very cool:) I can tell that ecj-bootstrap builds now! I am currently fiddeling manually around to get an openjdk (it won't happen on its own, since there is a cycle dependency). Therefore I injected some noarch packages from x86_64 and build some others manually for injection. If that works, we should become clean again on next rebuild. moin! adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Thursday 24 November 2011, Alexander Graf wrote:
So what is still missing from here?
* armv5 AFAIK it's currently built with gcc 4.4, but has ground to a halt due to a file conflict between libstdc++ 4.4 and 4.6. There is also a long-winded cycle between bison and translation-update-upstream. Although I was not able to find the libgmp used by the v5 gcc 4.6 anywhere, the armv7l libgmp worked as a drop-in replacement so I could build fixed binutils[*], gmp, and subsequently bison myself using 4.6, and they appear to work just fine. So if someone could disable the 4.4 overrides and inject the packages I built (including krb5 and gpm, two more cycle-creating packaging abominations), we might be able to get somewhere on v5 as well. Packages are here: ftp://ftp.suse.com/pub/people/uli/v5/ CU Uli [*] without gold (ICE) -- SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tuesday 29 November 2011, Ulrich Hecht wrote:
* armv5 So if someone could disable the 4.4 overrides and inject the packages I built (including krb5 and gpm, two more cycle-creating packaging abominations), we might be able to get somewhere on v5 as well.
I've removed the gcc44 overrides, but I can't inject packages. Lets see if there is a way to get along with 4.6 as well. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Dienstag, 29. November 2011, 13:11:26 schrieb Ulrich Hecht:
On Thursday 24 November 2011, Alexander Graf wrote:
So what is still missing from here?
* armv5
AFAIK it's currently built with gcc 4.4, but has ground to a halt due to a file conflict between libstdc++ 4.4 and 4.6. There is also a long-winded cycle between bison and translation-update-upstream.
Although I was not able to find the libgmp used by the v5 gcc 4.6 anywhere, the armv7l libgmp worked as a drop-in replacement so I could build fixed binutils[*], gmp, and subsequently bison myself using 4.6, and they appear to work just fine.
So if someone could disable the 4.4 overrides and inject the packages I built (including krb5 and gpm, two more cycle-creating packaging abominations), we might be able to get somewhere on v5 as well.
Packages are here: ftp://ftp.suse.com/pub/people/uli/v5/
They are inject now. Dirk removed already the 44 default it seems. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (7)
-
Adrian Schröter -
Alexander Graf -
Andrew Wafaa -
Dirk Müller -
Joop Boonen -
Tomas Cech -
Ulrich Hecht