Description of problem: When I build itext with the GCJ-AOT-bits compilation enabled as described in the guidelines, I get error messages during the find-debuginfo stage: extracting debug info from /var/tmp/itext-2.1.3-4.fc9-root-orcan/usr/lib64/gcj/itext/itext-2.1.3.jar.so cpio: itext-2.1.3/aot-compile-rpm/usr/lib64/gcj/itext/com/lowagie/text/factories/RomanNumberFactory$RomanDigit.java: Cannot stat: No such file or directory cpio: itext-2.1.3/aot-compile-rpm/usr/lib64/gcj/itext/com/lowagie/text/pdf/AcroFields$1.java: Cannot stat: No such file or directory cpio: itext-2.1.3/aot-compile-rpm/usr/lib64/gcj/itext/com/lowagie/text/pdf/AcroFields$InstHit.java: Cannot stat: No such file or directory cpio: itext-2.1.3/aot-compile-rpm/usr/lib64/gcj/itext/com/lowagie/text/pdf/AcroFields$Item.java: Cannot stat: No such file or directory cpio: itext-2.1.3/aot-compile-rpm/usr/lib64/gcj/itext/com/lowagie/text/pdf/AcroFields$RevisionStream.java: Cannot stat: No such file or directory ... Lots of them. I don't know the importance of these messages. But it seems like the debuginfo package is useless. Same problem can be produced if one enables compilation of GCJ-AOT bits in tuxguitar. Version-Release number of selected component (if applicable): 1.5.0 How reproducible: always Steps to Reproduce: 1. Download itext SRPM from rawhide. 2. Build it Actual results: Bunch of cpio errors during find-debuginfo stage. Expected results: I'm not sure, but having no error messages perhaps. Additional info: You can find the full itext build log at: http://kojipkgs.fedoraproject.org/packages/itext/2.1.3/4.fc10/data/logs/x86_64/build.log
Oh, no, not again! This keeps being broken. I'm looking.
OK, I found the cause of this problem. We used to have a hack in ecj where if we were building an RPM debuginfo was always generated. We have lost this hack, and so debuginfo is missing. We're looking at a way to fix this.
Orcan, we're going to fix this compiler bug, but you can make the problem go away now by editing build.xml and adding debug="on" to the <javac> task. e.g. <javac srcdir="${src}:${src2}" destdir="${build}" includes="mypackage/p1/**,mypackage/p2/**" excludes="mypackage/p1/testpackage/**" classpath="xyz.jar" debug="on" />
I've updated the patch and have a build going now. Orcan, if you could please test the resulting eclipse-ecj package (it'll take hours to build) and verify that with the existing one you get errors but with the updated one you get no errors, I would greatly appreciate it. http://koji.fedoraproject.org/koji/taskinfo?taskID=941824
Thanks for the quick fix (attempt). Let me explain what I did, step by step. - With the F-9 version of eclipse-ecj, I get those cpio errors when compiling itext. This is nothing new. BAD :( - Next, I added debug="on" on the javac part of the build script. When I built itext, the cpio errors were gone. GOOD :) - Next I upgraded the eclipse-ecj to the version built in koji that I got from the link Andrew O. gave. I removed debug="on" instances that I inserted before. I built itext. But I got cpio errors again. BAD :( - With the new eclipse-ecj, I re-added debug="on" on the javac part of the build script. Again the cpio errors are gone. GOOD :) So, I'm afraid the eclipse-ecj update didn't change anything (at least for itext).
F9's eclipse-ecj should have had that patch already. It only got removed in rawhide/F10. So I can see how this didn't change anything in this particular case.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This time, this happened to me on the build of bouncycastle: http://koji.fedoraproject.org/koji/buildinfo?buildID=94566 Passing -g to javac does not help. The weird thing is, bouncycastle-mail, which has the identical structure, does not have this problem: http://koji.fedoraproject.org/koji/buildinfo?buildID=94578 I wrote a build.xml file and used ant to build bouncycastle, and put debug="on" on the javac part of the xml file, but still the same thing happens. find-debuginfo cannot find the files it needs.
This is the link to the scratch build I made, using build.xml & ant: http://koji.fedoraproject.org/koji/taskinfo?taskID=1286180
The bouncycastle problem is due to the fact that the source tarball contains two copies of every .java file, one copy in the tarball and one copy in tarfile/src.zip. rpmbuild gets confused because it can't tell which .java file contains the actual source code. We need to delete one set of the source files.
Just add this line to the %prep phase before unzipping src.zip: find . -type f -name "*.java" -exec rm -f {} \; By the way, this new version of Bouncycastle doesn't build against gcj anyway, so you'll need to add a requires java-devel-openjdk as well as gcj.
(In reply to comment #10) > The bouncycastle problem is due to the fact that the source tarball contains > two copies of every .java file, one copy in the tarball and one copy in > tarfile/src.zip. rpmbuild gets confused because it can't tell which .java file > contains the actual source code. We need to delete one set of the source > files. That really doesn't explain why bouncycastle has this problem and bouncycastle-mail doesn't. Both have the same file structure. (In reply to comment #11) > Just add this line to the %prep phase before unzipping src.zip: > > find . -type f -name "*.java" -exec rm -f {} \; > > By the way, this new version of Bouncycastle doesn't build against gcj anyway, > so you'll need to add a requires java-devel-openjdk as well as gcj. Yes that's what I did in rawhide (BR'd java-devel-openjdk), I also disabled building of AOT bits.
Really, it's not interesting why bouncycastle has this problem and bouncycastle-mail doesn't. Both have the same file structure, therefore both are wrong. We shouldn't have multiple copies of the source code in the SRPM. Please don't disable building of AOT bits. We've got a fix now, so you don't have to do that. It'll still work fine with gcj at runtime.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping