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

["Harpal Grover" <harpal dot grover at gmail dot com>]

> 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.App$3 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.App$3" class.
"main.App" is the class which contains the main method. I am not sure
why it is looking for "main.App$3" 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