Patch for building Java compiler for version 4.3.0+
Yann E. MORIN
yann.morin.1998@anciens.enib.fr
Mon Jan 5 20:20:00 GMT 2009
Andy,
All,
On Monday 05 January 2009 16:26:40 Andy Johnson wrote:
> The Java compiler for GCC versions 4.3.0 and up requires the
> Eclipse compiler "ecj1" to be built as well.
Why is that? Isn't gcc able to build java by itself?
> I added "gcj" to
> the list of utilities to make the initial link:
OK. But know that if gcj is not present on the build system, you're
in trouble.
> --- /home/andy/cross-tool/crosstool-ng-1.3.1/scripts/crosstool.sh
> 2008-12-03 16:39:01.000000000 -0600
> +++ /usr/local/lib/ct-ng-1.3.1/scripts/crosstool.sh 2008-12-29
> 07:18:21.000000000 -0600
You diffed the source versus the installed files?!?!?
Applying such a patch is less than trivial.
Please, next time, use an SVN working copy, and run 'svn diff',
that'll give you a correct patch.
> @@ -329,7 +329,7 @@
> t="${!r}-"
> fi
>
> - for tool in ar as dlltool gcc g++ gnatbind gnatmake ld nm
> objcopy objdump ranlib strip windres; do
> + for tool in ar as dlltool gcc g++ gcj gnatbind gnatmake ld nm
> objcopy objdump ranlib strip windres; do
> # First try with prefix + suffix
> # Then try with prefix only
> # Then try with suffix only, but only for BUILD, and HOST
> iff REAL_BUILD == REAL_HOST
Hmm... Your mailer borked the patch...
> I also added some code to download ecj.jar if Java is selected:
I'd rather have that protected by a config option. Something like:
---8<--- BEGIN ---8<---
config CC_LANG_JAVA
bool
prompt "Java"
depends on CC_SUPPORT_JAVA
config CC_LANG_JAVA_USE_ECJ
bool
prompt "Use Eclipse Java Compiler (ecj)"
depends on CC_LANG_JAVA
---8<--- END ---8<---
as I don't see how ecj *is* necessary.
> --- /home/andy/cross-tool/crosstool-ng-1.3.1/scripts/build/cc/gcc.sh
> 2008-11-13 12:22:23.000000000 -0600
> +++ /usr/local/lib/ct-ng-1.3.1/scripts/build/cc/gcc.sh 2008-12-30
> 07:29:19.000000000 -0600
> @@ -18,11 +18,20 @@
> # subdirectory! You bastard!
> CT_GetFile "${CT_CC_FILE}" \
>
> {ftp,http}://ftp.gnu.org/gnu/gcc{,{,/releases}/${CT_CC_FILE}}
> + # Starting with GCC 4.3, ecj is used for Java, and will only be
> + # built if the configure script finds ecj.jar at the top of the
> + # GCC source tree, which will not be there unless we get it and
> + # put it there ourselves
> + [ "${CT_CC_LANG_JAVA}" = "y" -a "${CT_CC_GCC_4_3_or_later}" = "y" ]
> && \
> + CT_GetFile "ecj-latest.jar" ftp://gcc.gnu.org/pub/java
> }
>
> # Extract gcc
> do_cc_extract() {
> CT_ExtractAndPatch "${CT_CC_FILE}"
> + # Copy ecj-latest.jar to ecj.jar at the top of the GCC source tree
> + [ "${CT_CC_LANG_JAVA}" = "y" -a "${CT_CC_GCC_4_3_or_later}" = "y" ]
> && \
> + CT_DoExecLog ALL cp ${CT_LOCAL_TARBALLS_DIR}/ecj-latest.jar
> ${CT_SRC_DIR}/${CT_CC_FILE}/ecj.jar
> }
Patch still borked...
Would you mind reworking your patch against current SVN trunk, with
ecj usage protected behind a config option, please? And attach your
patch so your mailer does not bork it again. ;-)
> I have only tested this with ARM so far, both glibc and uClibc.
> At least I am now able to build ARM binaries from Java sources.
Tested: good. :-)
> Unfortunately, I have now reached a new problem: My tool-chain
> is much newer than my embedded device (by four years).
So? Device is HW, toolchain is SW. Surely you can make your /new/ software
run on /old/ hardware...
> I get errors such as the following:
> ./Reverse: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required
> by ./libgcj.so.9)
> ./Reverse: /lib/libpthread.so.0: version `GLIBC_2.3.2' not found
> (required by ./libgcj.so.9)
> ./Reverse: /lib/libc.so.6: version `GLIBC_2.3' not found (required by
> ./libgcj.so.9)
Aren't you mixing runtime libraries on your target? Seems like you're using
an /old/ existing library on your target, and the /old/ dynamic linker (the
one in /lib/ld.so) gets run instead of the new one.
> If I copy these files into a directory and set LD_LIBRARY_PATH, then I
> get this error:
> Inconsistency detected by ld.so: dynamic-link.h: 62:
> elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
It's still the dynamic linker in /lib that gets run. If you can't replace
the existing system, try chroot-ing.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ___ |
| --==< ^_^ >==-- `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
`------------------------------^-------^------------------^--------------------'
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list