jc1 out of memory error gcc 4.2.2 Linux 64-bit OS

Fri Jan 18 10:50:00 GMT 2008

> Maybe you didn't compile your program with -g ? Do so.

I have now added this option to the compile line :
gcj -O -g -fjni -findirect-dispatch "--classpath=
 C:/lib/x1.jar;C:/lib/x2.jar" --main=main.App -o scnlm.exe y1.class
 y2.class -LC:/projects/java/TSCN/Desktop/3232 -lswt -lswt-win32-3232
However, I still had the same stacktrace appear.
> This can be really painful. Sometimes, things are looked up by name
> (i.e. strings rather than symbols) so things don't get linked in.
>> You can solve this with
> --whole-archive
> For each archive mentioned on the command line after the
> --whole-archive option, include every
> object file in the archive in the link, rather than searching
> the archive for the required
> object files. This is normally used to turn an archive
> file into a shared library, forcing
> every object to be included in the resulting shared library.
> This option may be used more
> than once.
>> Two notes when using this option from gcc: First, gcc
> doesn't know about this option, so you
> have to use -Wl,-whole-archive. Second, don't forget to use
> -Wl,-no-whole-archive after your
> list of archives, because gcc will add its own list of
> archives to your link and you may not
> want this flag to affect those as well.

I have now added this to the compile line:
gcj -O -g -fjni -findirect-dispatch "--classpath=
 C:/lib/x1.jar;C:/lib/x2.jar" --main=main.App -o scnlm.exe y1.class
y2.class -LC:/projects/java/TSCN/Desktop/3232 -Wl,--whole-archive
libswt.a -Wl,--no-whole-archive -lswt -lswt-win32-3232
I was able to compile another exe successfully. However, gcj
complained about not being able to find a jar, which was included in
libswt.a. So I ended up taking out all of the jars from libswt.a
except for swt.jar.
I then changed my new command line to:
gcj -O -g -fjni -findirect-dispatch "--classpath=
 C:/lib/x1.jar;C:/lib/x2.jar" --main=main.App C:/lib/x1.o C:/lib/x2.o
-o scnlm.exe y1.class y2.class -LC:/projects/java/TSCN/Desktop/3232
-Wl,--allow-multiple-definition -lswt -lswt-win32-3232
And voila, a full executable was created. I was able to launch it and
my SWT application appears with no problems so far. I closed the app
down, and moved the executable to another folder along with its
required libraries. I then tried to launch it from within this new
folder and I got this stacktrace:
Exception in thread "main" java.lang.NoClassDefFoundError: main.App
 at java.lang.Class.initializeClass(/datal/gcc/gcc/gcc/libgcc2.c:0)
Caused by: java.lang.ClassNotFoundException: main.App3ドル not found in gnu.gcj.run
time.SystemClassLoader{urls=[file:.\], parent=gnu.gcj.runtime.ExtensionClassLoad
er{urls=[], parent=null}}
 at java.net.URLClassLoader.findClass(/datal/gcc/gcc/libjava/java/net/URLClass
Loader.java:1080)
 at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:351)
 at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:295)
 at java.lang.Class.initializeClass(/datal/gcc/gcc/gcc/libgcc2.c:0)
For some odd reason, it is looking for a class file which should have
been compiled into my native executable. My native executable is 57
MB. The really strange thing is gcj is looking for "main.App3ドル" class.
"main.App" is the class which contains the main method. I am not sure
why it is looking for "main.App3ドル" instead. Am I missing an additional
step of compiling the class files into the executable, so the
executable can finally be independent from the class files?
If I drop the native executable back into its original folder, it
launches fine again because it can see all of these classes again... I
know I am really close to finally getting this thing to compile, and
run smoothly. This is baffling me...
-- 
Harpal Grover
President
Harpal Grover Consulting Inc