Re: ecj1 in cross-compile

Daniel Andrzejewski <[email protected]>
Newsgroups gmane.comp.gcc.java.devel
Message-ID <[email protected]>


Andrew Haley wrote:
> 
> Daniel Andrzejewski wrote:
>> 
>> 
>> Andrew Haley wrote:
>>> Daniel Andrzejewski wrote:
>>>>
>>>> David Daney wrote:
>>>>> Andrew Haley wrote:
>>>>>> Matthijs van de Water wrote:
>>>>>>
>>>>>>   
>>>>>>> I've got my GCC 4.3 toolchain working ok now, but for some reason I
>>>>>>> fail to get an ecj1 binary.
>>>>>>>
>>>>>>> I'm cross-compiling for ARM and I've tried --with-ecj-jar=XXX (which
>>>>>>> doesn't result in an ecj1) and also tried putting ecj.jar in my
>>>>>>> build
>>>>>>> dir (which complains about a missing java compiler).
>>>>>>> I must be doing something wrong, but I'm not sure what.
>>>>>>>
>>>>>>> I expect an i686 ecj1 binary to be compiled from the ecj-latest.jar
>>>>>>> that I download in my build. Preferably standalone, like the Ubuntu
>>>>>>> one.
>>>>>>> The build machine doesn't have an i686 GCJ or JAVAC installed, is
>>>>>>> that
>>>>>>> a problem?
>>>>>>>
>>>>>>> What am I missing?
>>>>>>>     
>>>>>> I don't know how you think this is going to work.  ecj1 is a Java
>>>>>> program
>>>>>> and thus it needs some sort of Java runtime library.  You are going
>>>>>> to
>>>>>> need
>>>>>> an i686 gcj installed.  
>>>>> That's right.  It is a new requirement for GCC-4.3 cross compilers.
>>>>> Either install a native build of gcj/libgcj in your PATH, or as Andrew
>>>>> suggested use the little shell script to invoke the jar file.
>>>>>
>>>>> You have to be careful though, if you may not always want a native
>>>>> GCC-4.3 in your PATH, perhaps only when invoking the cross compiler.
>>>>> You could just copy or link the native ecj1 to the cross compiler bin
>>>>> directory.
>>>>>
>>>>> David Daney
>>>>>
>>>>>
>>>>>
>>>> Hi,
>>>>
>>>> I have successfully compiled gcc-4.3.0. I need to cross-compile java
>>>> code
>>>> to
>>>> binary executables which wouldn't need shared libraries. So, I used
>>>> options
>>>> like 
>>>> --disable-shared
>>>> --enable-languages=java
>>>> --with-ecj-jar=/home/daniel/ecj.jar
>>>>
>>>> Now, when I try to compile a java program I get the following error:
>>>>
>>>> ~> gcj --main=HelloWorld -o HelloWorld HelloWorld.java
>>>>
>>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>>> org.eclipse.jdt.internal.compiler.batch.GCCMain
>>>>    at gnu.java.lang.MainThread.run(MainThread.java:102)
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
>>>> gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
>>>> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
>>>>    at java.net.URLClassLoader.findClass(URLClassLoader.java:529)
>>>>    at java.lang.ClassLoader.loadClass(ClassLoader.java:442)
>>>>    at java.lang.ClassLoader.loadClass(ClassLoader.java:377)
>>>>    at gnu.java.lang.MainThread.run(MainThread.java:98)
>>>>
>>>>
>>>> I cannot figure out what to fix. I tried to move the existing ecj1
>>>> file,
>>>> and
>>>> that's what I got:
>>>>
>>>> ~> gcj --main=HelloWorld -o HelloWorld HelloWorld.java
>>>>
>>>> gcj: error trying to exec 'ecj1': execvp: Permission denied
>>>>
>>>>
>>>> It's understandable, I just renamed the ecj1 to something else.
>>>>
>>>> Now, when I use a short bash script that is provided above, I get
>>>> different
>>>> error:
>>>>
>>>> ~> gcj --main=HelloWorld -o HelloWorld HelloWorld.java
>>>>
>>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>>> org.eclipse.jdt.internal.compiler.batch.GCCMain
>>>> *** Got java.lang.NullPointerException while trying to print stack
>>>> trace.
>>> My bash script is:
>>>
>>> #!/bin/sh
>>> gij -cp /home/aph/gcc/trunk/ecj.jar \
>>>     org.eclipse.jdt.internal.compiler.batch.GCCMain \
>>>     ${1+"$@"}
>>>
>>> Andrew.
>>>
>>>
>> 
>> So, I used your script, just made an adjustment to the path to ecj.jar
>> file,
>> and as I mentioned earlier, I got this error:
>> 
>> Exception in thread "main" java.lang.NoClassDefFoundError:
>> org.eclipse.jdt.internal.compiler.batch.GCCMain
>> *** Got java.lang.NullPointerException while trying to print stack trace. 
>> 
>> What should I fix? I seem to get stuck.
> 
> In your gcc 4.3 build directory, type:
> 
> make check-target-libjava
> 
> Andrew.
> 
> 

Hi Andrew,

Thank you for your reply. 

I'm going to try 'make check-target-libjava', but for now it looks like I
found the solution to my compilation problem:

export CLASSPATH=.:/home/scratch/daniel/:/sw/java-jdk/ecj.jar

~> /scratch/daniel> gcj --main=HelloWorld -o HelloWorld HelloWorld.java
~> /scratch/daniel> ./HelloWorld
Hello World!

Success! But ...

~> /scratch/daniel> file HelloWorld

HelloWorld: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped

~> /scratch/daniel> ldd HelloWorld
        libm.so.6 => /lib64/tls/libm.so.6 (0x00002b1b953be000)
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002b1b95515000)
        librt.so.1 => /lib64/tls/librt.so.1 (0x00002b1b95629000)
        libz.so.1 => /lib64/libz.so.1 (0x00002b1b95732000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b1b95845000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x00002b1b95948000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
(0x00002b1b952a7000)


I really need to build gcc with static libraries, so my final result would
look like this:

daniel@acai ~/mpi> ldd hello
        not a dynamic executable

daniel@acai ~/mpi> file hello
hello: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.4.1, statically linked, for GNU/Linux 2.4.1, not stripped


What should I do? Do you have any suggestions? 

Regards,

Daniel Andrzejewski

-- 
View this message in context: http://www.nabble.com/ecj1-in-cross-compile-tp17771813p18984135.html
Sent from the gcc - java mailing list archive at Nabble.com.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.