Description of problem: While attempting to build Anthony's RSSOwl RPMs [1], I needed to first build his itext RPM [2]. I was trying this on my iBook which is running rawhide. The bytecode compilation goes fine, but when aot-compile-rpm attempts to natively-compile the jar, it does not seem to finish and uses lots of my 768 MB memory (over half when I stopped the process after 40 minutes). Version-Release number of selected component (if applicable): gcc-4.1.0-0.12.ppc How reproducible: Always (it happens if I install itext's jar and attempt to build RSSOwl native as well). Steps to Reproduce: 1. grab Anthony's itext SRPM [3] 2. rpmbuild --rebuild OR 1. wget http://overholt.ca/itext-1.3.jar.1.jar 2. gcj -shared -O2 -g -fsigned-char -fPIC -findirect-dispatch -fjni -Wl,-Bsymbolic itext-1.3.jar.1.jar -o itext-1.3.jar.so Actual results: Process seemingly hangs in jc1: ++ /usr/bin/gcj -shared -O2 -g -fsigned-char -fPIC -findirect-dispatch -fjni -Wl,-Bsymbolic /var/tmp/itext-1.3-1jpp_2-root-andrew/usr/lib/gcj/itext/itext-1.3.jar.1.jar -o /var/tmp/itext-1.3-1jpp_2-root-andrew/usr/lib/gcj/itext/itext-1.3.jar.so jc1: warning: command line option "-fsigned-char" is valid for C/C++/ObjC/ObjC++ but not for Java Expected results: jc1 completes in a reasonable amount of time. Additional info: I tried removing -fsigned-char but it didn't appear to be the problem. I can make my laptop available to someone if they want. Also, I doubt this happens on i386 or Anthony probably would not have submitted his SRPMs for Extras. I did not try to reproduce on i386 yet, though. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176982 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176981 [3] http://people.redhat.com/green/FE/devel/itext-1.3-1jpp_2.src.rpm
(In reply to comment #0) > Also, I doubt this happens on > i386 or Anthony probably would not have submitted his SRPMs for Extras. I did > not try to reproduce on i386 yet, though. > Don't be so sure! :-) I had my system RPM optimization flags set to -O0, since I've been doing so much debugging recently. I'm going an optimized build now and it's getting fat and slow. If I modify this to be a noarch RPM, will people have problems upgrading when we switch it over to a native RPM? I seem to remember yum having problems with this.
(In reply to comment #1) > If I modify this to be a noarch RPM, will people have problems upgrading when we > switch it over to a native RPM? I seem to remember yum having problems with this. > I'm pretty sure these all got fixed. Tom Fitzsimmons would know for sure. Tom?
Go to aot-compile-rpm and revise these numbers downwards: MAX_CLASSES_PER_JAR = 1024 MAX_BYTES_PER_JAR = 2097152 Tell us what you find.
(In reply to comment #1) > I'm going an optimized build now and it's getting fat and > slow. It eventually finished OK (x86 w/ optimization).
(In reply to comment #3) > Go to aot-compile-rpm and revise these numbers downwards: > > MAX_CLASSES_PER_JAR = 1024 > MAX_BYTES_PER_JAR = 2097152 > > Tell us what you find. I forgot to post here: I tried lower numbers ((512, 0), (1024, 512)) and it worked in both cases. Shall I try other combinations?
No. It works, it's good enough.
Cool, closing.