Re: Patch for building Java compiler for version 4.3.0+

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

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