Description of problem:
While attempting to build Anthony's RSSOwl RPMs , I needed to first build his
itext RPM . 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):
Always (it happens if I install itext's jar and attempt to build RSSOwl native
Steps to Reproduce:
1. grab Anthony's itext SRPM 
2. rpmbuild --rebuild
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
Process seemingly hangs in jc1:
++ /usr/bin/gcj -shared -O2 -g -fsigned-char -fPIC -findirect-dispatch -fjni
jc1: warning: command line option "-fsigned-char" is valid for C/C++/ObjC/ObjC++
but not for Java
jc1 completes in a reasonable amount of time.
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.
(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
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
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.