[opensuse-arm] ecj-bootstrap build failure / gcj issues
Hi, (braindump as I am out of time). while debugging the ecj-bootstrap buildfailure, I found a small reproducer: gij --verbose:class --classpath /usr/lib/gcc/armv7hl-suse-linux- gnueabi/4.7/ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain which gives ... [Loaded (bytecode) org.eclipse.jdt.core.compiler.IProblem from (file:/usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.7/ecj.jar <no certificates>)] .... Exception in thread "main" [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder from <no code source>] [Loaded (pre-compiled) java.lang.Throwable$StaticData from <no code source>] java.lang.NoClassDefFoundError: org.eclipse.jdt.core.compiler.IProblem <<No stacktrace available>> with other words, it can load the class it complains about. However, there is a hint: http://www.mail-archive.com/debian-68k@lists.debian.org/msg15345.html which says, there might still be an undefined class, and it is not the one it mentions but one of the referenced ones. anyone having time to search for it ? TIA, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.07.2012, at 11:05, Dirk Müller <dmueller@suse.com> wrote:
Hi,
(braindump as I am out of time). while debugging the ecj-bootstrap buildfailure, I found a small reproducer:
gij --verbose:class --classpath /usr/lib/gcc/armv7hl-suse-linux- gnueabi/4.7/ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain
which gives
... [Loaded (bytecode) org.eclipse.jdt.core.compiler.IProblem from (file:/usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.7/ecj.jar <no certificates>)] ....
Exception in thread "main" [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder from <no code source>] [Loaded (pre-compiled) java.lang.Throwable$StaticData from <no code source>] java.lang.NoClassDefFoundError: org.eclipse.jdt.core.compiler.IProblem <<No stacktrace available>>
with other words, it can load the class it complains about. However, there is a hint:
http://www.mail-archive.com/debian-68k@lists.debian.org/msg15345.html
which says, there might still be an undefined class, and it is not the one it mentions but one of the referenced ones.
anyone having time to search for it ?
strace should be able to tell you, no? Unless there is a cache of course :). Alex
TIA, Dirk -- 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 07.07.2012, at 15:34, Alexander Graf wrote:
On 07.07.2012, at 11:05, Dirk Müller <dmueller@suse.com> wrote:
Hi,
(braindump as I am out of time). while debugging the ecj-bootstrap buildfailure, I found a small reproducer:
gij --verbose:class --classpath /usr/lib/gcc/armv7hl-suse-linux- gnueabi/4.7/ecj.jar org.eclipse.jdt.internal.compiler.batch.GCCMain
which gives
... [Loaded (bytecode) org.eclipse.jdt.core.compiler.IProblem from (file:/usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.7/ecj.jar <no certificates>)] ....
Exception in thread "main" [Loaded (pre-compiled) gnu.gcj.runtime.NameFinder from <no code source>] [Loaded (pre-compiled) java.lang.Throwable$StaticData from <no code source>] java.lang.NoClassDefFoundError: org.eclipse.jdt.core.compiler.IProblem <<No stacktrace available>>
with other words, it can load the class it complains about. However, there is a hint:
http://www.mail-archive.com/debian-68k@lists.debian.org/msg15345.html
which says, there might still be an undefined class, and it is not the one it mentions but one of the referenced ones.
anyone having time to search for it ?
strace should be able to tell you, no? Unless there is a cache of course :).
This is where the x86 (working) and arm (broken) cases diverge. So I'd assume the breakage is a missing LinkedHashSet implementation? Just a wild guess though. x86: [pid 1734] lstat("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 1734] open("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", O_RDONLY) = 4 [pid 1734] stat("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 1734] stat("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 1734] read(4, "\312\376\272\276\0\0\0.\0Y\7\0\2\1\0005org/eclipse/jdt/"..., 2337) = 2337 [pid 1734] close(4) = 0 [pid 1734] write(2, "[Loaded (pre-compiled) java.lang"..., 62[Loaded (pre-compiled) java.lang.Float from <no code source>] ) = 62 [pid 1734] write(2, "[Loaded (bytecode) org.eclipse.j"..., 108[Loaded (bytecode) org.eclipse.jdt.internal.compiler.util.HashtableOfInt from (file:/x/ <no certificates>)] ) = 108 [pid 1734] write(2, "[Loaded (pre-compiled) java.util"..., 70[Loaded (pre-compiled) java.util.LinkedHashSet from <no code source>] ) = 70 [pid 1734] write(2, "[Loaded (pre-compiled) java.util"..., 70[Loaded (pre-compiled) java.util.LinkedHashMap from <no code source>] ) = 70 [pid 1734] write(2, "[Loaded (pre-compiled) java.util"..., 86[Loaded (pre-compiled) java.util.LinkedHashMap$LinkedHashEntry from <no code source>] ) = 86 [pid 1734] write(2, "[Loaded (pre-compiled) java.util"..., 72[Loaded (pre-compiled) java.util.LinkedHashMap$1 from <no code source>] ) = 72 ---- arm: [pid 8468] lstat64("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 8468] open("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", O_RDONLY|O_LARGEFILE) = 4 [pid 8468] stat64("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 8468] stat64("/x/org/eclipse/jdt/internal/compiler/util/HashtableOfInt.class", {st_mode=S_IFREG|0644, st_size=2337, ...}) = 0 [pid 8468] read(4, "\312\376\272\276\0\0\0.\0Y\7\0\2\1\0005org/eclipse/jdt/"..., 2337) = 2337 [pid 8468] close(4) = 0 [pid 8468] write(2, "[Loaded (pre-compiled) java.lang"..., 62[Loaded (pre-compiled) java.lang.Float from <no code source>] ) = 62 [pid 8468] write(2, "[Loaded (bytecode) org.eclipse.j"..., 108[Loaded (bytecode) org.eclipse.jdt.internal.compiler.util.HashtableOfInt from (file:/x/ <no certificates>)] ) = 108 [pid 8468] cacheflush(0xb42cb0d8, 0xb42cb0eb, 0, 0x71a8, 0xb42cb0d8) = 0 [pid 8468] cacheflush(0xb42cb0d8, 0xb42cb0e4, 0, 0x71a8, 0xb42cb0d8) = 0 [pid 8468] cacheflush(0xb42cb140, 0xb42cb153, 0, 0x71a8, 0xb42cb140) = 0 [pid 8468] cacheflush(0xb42cb140, 0xb42cb14c, 0, 0x71a8, 0xb42cb140) = 0 [pid 8468] cacheflush(0xb42cb1b0, 0xb42cb1c3, 0, 0x71a8, 0xb42cb1b0) = 0 [pid 8468] cacheflush(0xb42cb1b0, 0xb42cb1bc, 0, 0x71a8, 0xb42cb1b0) = 0 [pid 8468] cacheflush(0xb42cb220, 0xb42cb233, 0, 0x71a8, 0xb42cb220) = 0 [pid 8468] cacheflush(0xb42cb220, 0xb42cb22c, 0, 0x71a8, 0xb42cb220) = 0 [pid 8468] cacheflush(0xb42cb290, 0xb42cb2a3, 0, 0x71a8, 0xb42cb290) = 0 [pid 8468] cacheflush(0xb42cb290, 0xb42cb29c, 0, 0x71a8, 0xb42cb290) = 0 [pid 8468] cacheflush(0xb42cb300, 0xb42cb313, 0, 0x71a8, 0xb42cb300) = 0 [pid 8468] cacheflush(0xb42cb300, 0xb42cb30c, 0, 0x71a8, 0xb42cb300) = 0 [pid 8468] cacheflush(0xb42cb368, 0xb42cb37b, 0, 0x71a8, 0xb42cb368) = 0 [pid 8468] cacheflush(0xb42cb368, 0xb42cb374, 0, 0x71a8, 0xb42cb368) = 0 [pid 8468] cacheflush(0xb42cb3d0, 0xb42cb3e3, 0, 0x71a8, 0xb42cb3d0) = 0 [pid 8468] cacheflush(0xb42cb3d0, 0xb42cb3dc, 0, 0x71a8, 0xb42cb3d0) = 0 [pid 8468] write(2, "Exception in thread \"main\" ", 27Exception in thread "main" ) = 27 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Sunday 08 July 2012, Alexander Graf wrote:
This is where the x86 (working) and arm (broken) cases diverge. So I'd assume the breakage is a missing LinkedHashSet implementation? Just a wild guess though.
Hi, no. also not caused by MALLOC_CHECK_ though. after digging a bit with gdb, I suspect libffi, we're still using 3.0.9 (as part of the gcc47 source tree), while it seems that 3.0.10 (used by Fedora and Debian I think) as several arm related fixes. http://lists.debian.org/debian-arm/2011/04/msg00091.html seems to indicate that this might be a solution. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11.07.2012, at 17:14, Dirk Müller wrote:
On Sunday 08 July 2012, Alexander Graf wrote:
This is where the x86 (working) and arm (broken) cases diverge. So I'd assume the breakage is a missing LinkedHashSet implementation? Just a wild guess though.
Hi,
no. also not caused by MALLOC_CHECK_ though. after digging a bit with gdb, I suspect libffi, we're still using 3.0.9 (as part of the gcc47 source tree), while it seems that 3.0.10 (used by Fedora and Debian I think) as several arm related fixes.
http://lists.debian.org/debian-arm/2011/04/msg00091.html
seems to indicate that this might be a solution.
Wow - who would've guessed? Should be easy enough to create a small branch that contain new libffi and links gcj, so we get it rebuilt with the new one, right? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wednesday 11 July 2012, Alexander Graf wrote:
Wow - who would've guessed? Should be easy enough to create a small branch that contain new libffi and links gcj, so we get it rebuilt with the new one, right?
Yes, I'll do that. the symptom that points into that direction is that it works on the softfp target (armv5el). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11.07.2012, at 17:14, Dirk Müller wrote:
On Sunday 08 July 2012, Alexander Graf wrote:
This is where the x86 (working) and arm (broken) cases diverge. So I'd assume the breakage is a missing LinkedHashSet implementation? Just a wild guess though.
Hi,
no. also not caused by MALLOC_CHECK_ though. after digging a bit with gdb, I suspect libffi, we're still using 3.0.9 (as part of the gcc47 source tree), while it seems that 3.0.10 (used by Fedora and Debian I think) as several arm related fixes.
http://lists.debian.org/debian-arm/2011/04/msg00091.html
seems to indicate that this might be a solution.
Well, why not just ask him? :) [5:58pm]agraf:markos_: ping [5:58pm]agraf:markos_: you were fiddling with gcj on armhf, right? [5:59pm]agraf:markos_: what exactly was the breakage you saw there? we're currently having issues where gcj can't find classes even though it does load them [6:02pm] zyga left the chat room. (Quit: Ex-Chat) [6:04pm]markos_:agraf, well I wasn't really messing too much with gcj's internals [6:04pm]agraf:markos_: well, i did read a post from you about libffi and was wondering if that's what fixed it for you [6:04pm]agraf:markos_: also if the breakage you saw was in fact the same [6:05pm] [6:05pm]markos_:no, in fact, it was a patch from Andrew Hailey (or Haley keep forgetting), that completely fixed gcj upstream [6:05pm]agraf:oh? [6:06pm]markos_:the problem in my case wasn't gcj, but gij -which in Debian used ecj [6:06pm]markos_:gcj just builds native code [6:06pm]markos_:this worked [6:06pm]markos_:gij however didn't [6:06pm]agraf:ah, right, sorry, same here [6:06pm]agraf:gij is having trouble resolving classes [6:06pm]agraf:while running ecj [6:06pm]agraf:so it sounds very similar indeed [6:06pm]markos_:I got divisions by zero errors etc [6:07pm]agraf:can you remember what exactly the fix was and where i could find it? [6:07pm]agraf:hrm - I don't see division by zero errors, but that doesn't mean much i suppose [6:07pm]markos_:not really, as I said, it was magically fixed at one point with gcj 4.6 iirc [6:08pm]agraf:ah, ok [6:08pm]agraf:yeah, 4.6 worked for us too [6:08pm]agraf:4.7 is broken again [6:08pm]markos_:oh [6:09pm]markos_:seems to have built on debian (4.7.1-1) [6:09pm]agraf:it does build just fine [6:09pm]agraf:but executing ecj fails [6:09pm]markos_:ok, will try that here [6:09pm]agraf:would be great to see if it fails for you too, yeah -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 11.07.2012, at 18:11, Alexander Graf wrote:
On 11.07.2012, at 17:14, Dirk Müller wrote:
On Sunday 08 July 2012, Alexander Graf wrote:
This is where the x86 (working) and arm (broken) cases diverge. So I'd assume the breakage is a missing LinkedHashSet implementation? Just a wild guess though.
Hi,
no. also not caused by MALLOC_CHECK_ though. after digging a bit with gdb, I suspect libffi, we're still using 3.0.9 (as part of the gcc47 source tree), while it seems that 3.0.10 (used by Fedora and Debian I think) as several arm related fixes.
http://lists.debian.org/debian-arm/2011/04/msg00091.html
seems to indicate that this might be a solution.
Well, why not just ask him? :)
[5:58pm]agraf:markos_: ping [5:58pm]agraf:markos_: you were fiddling with gcj on armhf, right? [5:59pm]agraf:markos_: what exactly was the breakage you saw there? we're currently having issues where gcj can't find classes even though it does load them [6:02pm] zyga left the chat room. (Quit: Ex-Chat) [6:04pm]markos_:agraf, well I wasn't really messing too much with gcj's internals [6:04pm]agraf:markos_: well, i did read a post from you about libffi and was wondering if that's what fixed it for you [6:04pm]agraf:markos_: also if the breakage you saw was in fact the same [6:05pm] [6:05pm]markos_:no, in fact, it was a patch from Andrew Hailey (or Haley keep forgetting), that completely fixed gcj upstream [6:05pm]agraf:oh? [6:06pm]markos_:the problem in my case wasn't gcj, but gij -which in Debian used ecj [6:06pm]markos_:gcj just builds native code [6:06pm]markos_:this worked [6:06pm]markos_:gij however didn't [6:06pm]agraf:ah, right, sorry, same here [6:06pm]agraf:gij is having trouble resolving classes [6:06pm]agraf:while running ecj [6:06pm]agraf:so it sounds very similar indeed [6:06pm]markos_:I got divisions by zero errors etc [6:07pm]agraf:can you remember what exactly the fix was and where i could find it? [6:07pm]agraf:hrm - I don't see division by zero errors, but that doesn't mean much i suppose [6:07pm]markos_:not really, as I said, it was magically fixed at one point with gcj 4.6 iirc [6:08pm]agraf:ah, ok [6:08pm]agraf:yeah, 4.6 worked for us too [6:08pm]agraf:4.7 is broken again [6:08pm]markos_:oh [6:09pm]markos_:seems to have built on debian (4.7.1-1) [6:09pm]agraf:it does build just fine [6:09pm]agraf:but executing ecj fails [6:09pm]markos_:ok, will try that here [6:09pm]agraf:would be great to see if it fails for you too, yeah
[6:12pm]markos_:tbh, I hope it doesn't fail here, hehe [6:12pm]agraf:same here, because that means we can start diff'ing [6:12pm]markos_:anyway installing the packages, will take a while now, i'm on vac and the line is just 2Mbit [6:13pm]agraf:http://lists.opensuse.org/opensuse-arm/2012-07/msg00021.html [6:13pm]agraf:if you're interested in a few more details [6:15pm]markos_:ouch, right, the HashtableOfInt [6:15pm]markos_:there was a division by zero somewhere there [6:16pm]markos_:but I see that you're still using libffi 3.0.9, while not directly related, it might be a good idea to upgrade to 3.0.10 [6:18pm]markos_:the mail linked from April 2011 suggests that libffi was the reason gcj broke, it actually wasn't, Andrew did some other fixes in gcj and got 4.6 working [6:19pm]Neko:yergh!!! [6:25pm]markos_:agraf, building ecj using gcj-4.7 now, seems to work fine [6:26pm]markos_:both stages, gcj and gij [6:26pm]agraf:markos_: odd [6:27pm]agraf:markos_: can it actually run ecj? [6:27pm]markos_:it is [6:27pm]agraf:wow [6:27pm]markos_:ecj is self-bootstrapping on debian [6:27pm]agraf:ah, makes sense [6:28pm]markos_:so using gcj to compile stuff from C/C++ but running gij +ecj afterwards to build the java stuff [6:28pm]agraf:so I suppose that's good news and means the next step would be to take a debian system, and replace our binaries bit by bit by yours until it works [6:28pm]agraf:should be close enough to make that possible [6:28pm]markos_:lots of java warning [6:28pm]markos_:or you could just take debian and stick with it [6:28pm]•markos_ runs [6:28pm]agraf:heh [6:30pm]markos_:for starters I'd suggest upgrading libffi [6:30pm]markos_:and see if it changes anything [6:30pm]agraf:nod [6:30pm]agraf:and if it doesn't, do the binary replacement fun [6:30pm]agraf:to at least narrow it down to a component [6:31pm]markos_:well, that's a way to pass the hot summer days [6:31pm]agraf:I'd be happy if they were hot -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Dirk Müller