Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

Hello,

I'm going to try to build
svn://gcc.gnu.org/svn/gcc/branches/ubuntu/gcc-4_2-branch
Which is essentially a copy of gcc-4_2-branch with gcc/java, libjava,
zlib, libffi and boehm-gc merged from GCC trunk.

This includes a working GCJ for ARM EABI, which is what I'm interested in.

I'm not sure how I should go about this and if maybe one of you have
already tried something like this or have suggestions before I dive
in. I've already checked and all patches that are in OE for GCC 4.2.2
still apply.

I was thinking of calling my package 'gcc-4.2.3-ubuntu' does that make sense?

For now, I simply copied 4.2.2*.bb and 4.2.2*.inc files to 4.2.3-ubuntu files:
    gcc_4.2.3-ubuntu.bb
    gcc-cross_4.2.3-ubuntu.bb
    gcc-4.2.3-ubuntu.inc
    gcc-cross-sdk_4.2.3-ubuntu.bb
    gcc-cross-initial_4.2.3-ubuntu.bb
    gcc-4.2.3-ubuntu

and changed gcc-4.2.3-ubuntu.inc to point its SRC_URI to svn, S to the
correct dir and enabled JAVA by
JAVA_linux-gnueabi = ",java"

I'm running a build now (but that tends to take quite a while) and
I'll report back my findings. Any suggestions or general explanations
of how all these packages work together are more than welcome, because
I'm not really sure what I'm doing...

Regards,

Matthijs van de Water

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Hi Matthijs,
I am interested in seeing a working GCJ on ARM EABI, too.

Matthijs van de Water schrieb:
> I was thinking of calling my package 'gcc-4.2.3-ubuntu' does that make sense?
For testing purposes it makes sense to

> For now, I simply copied 4.2.2*.bb and 4.2.2*.inc files to 4.2.3-ubuntu files:
>     gcc_4.2.3-ubuntu.bb
>     gcc-cross_4.2.3-ubuntu.bb
>     gcc-4.2.3-ubuntu.inc
>     gcc-cross-sdk_4.2.3-ubuntu.bb
>     gcc-cross-initial_4.2.3-ubuntu.bb
>     gcc-4.2.3-ubuntu
You do not need to modify gcc-cross-initial and gcc-cross-sdk in the
first place because the GCJ in them is not used at all. You need to
modify gcc-cross and gcc however.

You will use first to ahead-of-time compile your Java app and create the
db file. The latter contains gij which you have to put on your target
device.

> and changed gcc-4.2.3-ubuntu.inc to point its SRC_URI to svn, S to the
> correct dir and enabled JAVA by
> JAVA_linux-gnueabi = ",java"
Not quite sure whether this is the way it is supposed to do. I thought
there is a variable enable_java or something like that in the recipes
which you have to set to 1 in your local.conf.

> I'm running a build now (but that tends to take quite a while) and
> I'll report back my findings. Any suggestions or general explanations
> of how all these packages work together are more than welcome, because
> I'm not really sure what I'm doing...
Please report your results.

If you get it working please try whether the GCJ patches can be applied
to any of the existing GCC versions within OE. That way all
distributions in OE can make use of it optionally (when they switch to
this GCC).

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

On Thu, Apr 10, 2008 at 4:33 PM, Robert Schuster <theBohemian@gmx.net> wrote:
> Hi Matthijs,
>  I am interested in seeing a working GCJ on ARM EABI, too.
Good, I hope we get it working :)

>  You do not need to modify gcc-cross-initial and gcc-cross-sdk in the
>  first place because the GCJ in them is not used at all. You need to
>  modify gcc-cross and gcc however.
I know they're not all needed to get a working arm-linux-gnueabi-gcj.
But I'm not sure if I should mix GCC versions...
So I changed my preferred version of GCC to '4.2.3-ubuntu' so that one
will be used in the entire build and started a clean build. I thought
I was a good idea to keep all gcc things that are built based on the
same code-base. Is that a wrong assumption? To test I just did a
"bitbake glibc" which I presume will build enough to know if things
work.

>  > and changed gcc-4.2.3-ubuntu.inc to point its SRC_URI to svn, S to the
>  > correct dir and enabled JAVA by
>  > JAVA_linux-gnueabi = ",java"
>  Not quite sure whether this is the way it is supposed to do. I thought
>  there is a variable enable_java or something like that in the recipes
>  which you have to set to 1 in your local.conf.
I cannot find something like that and it does look like I have to set
this JAVA, because it will end up in --enable-languages on the
configure command.

>  Please report your results.
The build has just failed on glibc-intermediate with a linking error:
cannot find -lgcc_eh. I'll look into that now.
It has finished building the following stuff:
binutils-cross-2.18-r1
gcc-cross-4.2.3-ubuntu-r6
gcc-cross-initial-4.2.3-ubuntu-r6
glibc-2.6.1-r3
glibc-intermediate-2.6.1-r3
linux-libc-headers-2.6.24-r2

>  If you get it working please try whether the GCJ patches can be applied
>  to any of the existing GCC versions within OE. That way all
>  distributions in OE can make use of it optionally (when they switch to
>  this GCC).
That patch will be massive: there are tons of new .java files....

Regards,
Matthijs

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]

HI Matthijs,

Matthijs van de Water schrieb:
> I know they're not all needed to get a working arm-linux-gnueabi-gcj.
> But I'm not sure if I should mix GCC versions...
> So I changed my preferred version of GCC to '4.2.3-ubuntu' so that one
> will be used in the entire build and started a clean build. I thought
> I was a good idea to keep all gcc things that are built based on the
> same code-base. Is that a wrong assumption? To test I just did a
> "bitbake glibc" which I presume will build enough to know if things
> work.
That is indeed a good idea. GCJ heavily relies on the BC ABI which is
defined for C++. If you use different compilers things may break.

>>  Please report your results.
> The build has just failed on glibc-intermediate with a linking error:
> cannot find -lgcc_eh. I'll look into that now.
> It has finished building the following stuff:
> binutils-cross-2.18-r1
> gcc-cross-4.2.3-ubuntu-r6
> gcc-cross-initial-4.2.3-ubuntu-r6
> glibc-2.6.1-r3
> glibc-intermediate-2.6.1-r3
> linux-libc-headers-2.6.24-r2
Have a look at gcc-4.2.2.inc. As you there are many patches applied
which for e.g. ARM. It is likely that you need to have those for your
GCC recipe, too.

>>  If you get it working please try whether the GCJ patches can be applied
>>  to any of the existing GCC versions within OE. That way all
>>  distributions in OE can make use of it optionally (when they switch to
>>  this GCC).
> That patch will be massive: there are tons of new .java files....
Which perhaps it makes sense then to get everything working from GCJ
4.3.0 onwards. AFAIK this release contains all the ARM GCJ stuff we need
and we can ask Andrew Haley if important GCJ patches have been
introduced after the 4.3.0 release.

GCC 4.3.0 support in OE is still in its infancy and requires some
workarounds. Keep an eye on this list for news about that.

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

gcc 4.3.0 status, was: Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Schuster schreef:

| Which perhaps it makes sense then to get everything working from GCJ
| 4.3.0 onwards. AFAIK this release contains all the ARM GCJ stuff we need
| and we can ask Andrew Haley if important GCJ patches have been
| introduced after the 4.3.0 release.
|
| GCC 4.3.0 support in OE is still in its infancy and requires some
| workarounds. Keep an eye on this list for news about that.

I had a look at gcc 4.3.0 last week (I need it for armv7-a[1] support),
and the situation has improved a bit:

* armv4t works again
* all debian and fedora patches were imported into OE

Debian has a few libjava patches that I didn't apply (they use a mixture
of p0 and p1 patches which I was too lazy to sort out, they are in
packages/gcc/gcc-4.3.0/debian/), so you could have a look at those.

There are still a few problems, one of which is the includes-fixed
problem, the other that gcc refuses to find stdlib.h even when passed
the correct -I${STAGING_INCDIR}. Gcc also likes to ICE like crazy on
*_Load.c in libmikmod. It's also lacking the uclibc patches.

regards,

Koen

[1] Starting with armv7 gcc distinguishes between various modes (arm,
thumb, etc), so you need to pass -march=armv7-a (the cortex-a8 tunefile
does that for you) if you want regular ARM mode and set PACKAGE_ARCH to
armv7a (without any hyphen, the cortex-a8 tunefile does that for you as
well).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFIAO2pMkyGM64RGpERAuafAJ9Vy39Qhs53IWBPww3PmBvyIPpsQQCfSTIC
NYTbeqatKb/vJL0RiQ8fbTI=
=rIdj
-----END PGP SIGNATURE-----

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

>  >  Please report your results.
>  The build has just failed on glibc-intermediate with a linking error:
>  cannot find -lgcc_eh. I'll look into that now.
I solved this: I was missing a BINV="4.2.3" in my new ubuntu.inc file.
I also needed to specify a "--disable-sjlj-exceptions" as EXTRA_OECONF
and found out that the EXTRA_OECONF from the .inc files in gcc are
overwritten. I patched gcc-configure-common.inc to fix that (I'll
submit a bugreport about this later):
--- meta/packages/gcc/gcc-configure-common.inc       (revision)
+++ meta/packages/gcc/gcc-configure-common.inc       (working copy)
@@ -13,7 +13,8 @@ JAVA_sh3 ?= ""
 FORTRAN ?= ",f77"
 LANGUAGES ?= "c,c++${FORTRAN}${JAVA}"

-EXTRA_OECONF = "${@['--enable-clocale=generic',
''][bb.data.getVar('USE_NLS', d, 1) != 'no']} \
+EXTRA_OECONF ?= ""
+EXTRA_OECONF += "${@['--enable-clocale=generic',
''][bb.data.getVar('USE_NLS', d, 1) != 'no']} \
                 --with-gnu-ld \
                 --enable-shared \
                 --enable-target-optspace \

This time the build successfully generated everything, including a GCJ
cross-compiler. It looks to be working, I'll report back after I've
run some tests with it.
I did need >512MB of memory while building and compiling libjava took
quite a while...

This leads me to think that it would be best to generate a special BB
file and package for GCJ, so that it does not have to be built always
and does not go into the SDK by default. libgcj.so and especially
libgcj.a are huge, I would not want them in my SDK by default. For my
embedded use, I'll also be modifying libgcj to trim down the size and
I'll probably be rebuilding it quite often while doing that. All the
more reason to split it out of the generic gcc-cross, although I'm not
sure how feasible that is and how to go about that.
Anyone have any ideas about that?

>  Have a look at gcc-4.2.2.inc. As you there are many patches applied
>  which for e.g. ARM. It is likely that you need to have those for your
>  GCC recipe, too.
Yes, all of those are applied.

>  Which perhaps it makes sense then to get everything working from GCJ
>  4.3.0 onwards. AFAIK this release contains all the ARM GCJ stuff we need
>  and we can ask Andrew Haley if important GCJ patches have been
>  introduced after the 4.3.0 release.
>
>  GCC 4.3.0 support in OE is still in its infancy and requires some
>  workarounds. Keep an eye on this list for news about that.
Sounds like a good idea for OE in general; I'll be sticking to 4.2.3
for my application however. Once 4.3.0 starts working, I'll see if I
can make the JAVA stuff work on that. The memory usage of the GCJ
compiler while building libjava is a concern though: I couldn't get
things compiled on my machine with 1GB of RAM. Only after putting 1GB
of extra RAM in my machine, I was able to compile nicely... On
dedicated build servers it might work with 1GB of RAM, but this is a
concern.

Regards,
Matthijs

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

Status update: I managed to get everything (also gcc-cross-sdk) to
compile (needed only 1 additional patch and 1GB of extra memory)
I now still need to:
1) Make sure that the relevant GCJ stuff gets packaged (in the current
state it's at least missing the java include files and the
libgcj-4.2.3.jar)
2) Split out all GCJ related stuff to compile in a separate set of
tasks so that it does not always get build, because this takes ages
and loads of memory.

I'm not sure about the best way to get (2)... any suggestions are welcome.

Regards,
Matthijs

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi.

Matthijs van de Water schrieb:
> 2) Split out all GCJ related stuff to compile in a separate set of
> tasks so that it does not always get build, because this takes ages
> and loads of memory.
I don't think that is possible atm. GCJ is part of a GCC build and can
only be enabled or disabled at configuration time.

I did a quick glance at the gcc-package-*.inc recipes and they do not
provide packaging info for GCJ specifically. So either things end up
in another binary package or they end up nowhere. I'll have a look at that.

> I'm not sure about the best way to get (2)... any suggestions are welcome.
> 
> Regards,
> Matthijs
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

Bad luck: my GCC/GCJ build seems flawless, but the filesystem I
generated with it fails to run a Java Hello World :(
It fails with a "terminate called without an active exception" before
doing anything.

I'll try to debug this, but I fear that I'll have to get this test
based on GCC 4.3 before I can get any real support from the gcc-java
mailing list...

Regards,
Matthijs

Re: gcc 4.3.0 status, was: Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

On Sat, Apr 12, 2008 at 7:13 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>  There are still a few problems, one of which is the includes-fixed
>  problem, the other that gcc refuses to find stdlib.h even when passed
>  the correct -I${STAGING_INCDIR}. Gcc also likes to ICE like crazy on
>  *_Load.c in libmikmod. It's also lacking the uclibc patches.

Any news on this?

I would be interested to have a look at this, but I'd appreciate a bit
more details on the errors you get and (where appropriate)
workarounds. I'd rather start from where you are than from scratch :)
Did http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html solve
the "include-fixed" problem for glibc?

Thanks,
Matthijs

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Robert Schuster]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hi Matthijs,

Matthijs van de Water schrieb:
> Bad luck: my GCC/GCJ build seems flawless, but the filesystem I
> generated with it fails to run a Java Hello World :(
> It fails with a "terminate called without an active exception" before
> doing anything.
> 
> I'll try to debug this, but I fear that I'll have to get this test
> based on GCC 4.3 before I can get any real support from the gcc-java
> mailing list...
Yeah, I've seen your thread over there. At least we have a good idea of
what is not working. Unfortunately I have this feeling that exception
handling on ARM with GCJ is an all time favorite. Hopefully we can get
things to fly with GCC 4.3 then.

Btw: Your statement that 4.3 is not widely in use is not quite right:
Fedora 9 and Debian Lenny are build with it or are in the process of
transition.

Regards
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

On Wed, Apr 23, 2008 at 9:33 AM, Robert Schuster <theBohemian@gmx.net> wrote:
>  Btw: Your statement that 4.3 is not widely in use is not quite right:
>  Fedora 9 and Debian Lenny are build with it or are in the process of
>  transition.
Ok. I'm not sure how widely deployed the Fedora and Debian ARM
distro's are, but that sounds at least positive.
I'm going to give GCC 4.3 a spin and report back.

Matthijs.

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

Robert Schuster wrote:

> Btw: Your statement that 4.3 is not widely in use is not quite right:
> Fedora 9 and Debian Lenny are build with it or are in the process of
> transition.

Sometimes, I think Fedora is a conspiracy to create a large pool of beta 
testers :) I should have tried OE on a F9 Preview box in a week or so.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Graeme Gregory]

On Wed, Apr 23, 2008 at 07:48:41AM -0400, Philip Balister wrote:
> Robert Schuster wrote:
>
>> Btw: Your statement that 4.3 is not widely in use is not quite right:
>> Fedora 9 and Debian Lenny are build with it or are in the process of
>> transition.
>
> Sometimes, I think Fedora is a conspiracy to create a large pool of beta 
> testers :) I should have tried OE on a F9 Preview box in a week or so.
>
Its not really a conspiracy, its the stated aim of fedora, to test
new features for RHEL :-)

Graeme

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Mark Brown]

On Wed, Apr 23, 2008 at 01:44:26PM +0200, Matthijs van de Water wrote:
> On Wed, Apr 23, 2008 at 9:33 AM, Robert Schuster <theBohemian@gmx.net> wrote:

> >  Btw: Your statement that 4.3 is not widely in use is not quite right:
> >  Fedora 9 and Debian Lenny are build with it or are in the process of
> >  transition.

> Ok. I'm not sure how widely deployed the Fedora and Debian ARM
> distro's are, but that sounds at least positive.
> I'm going to give GCC 4.3 a spin and report back.

Debian ARM gets a reasonable amount of use, especially now that various
NAS devices are supported by the installer, though it's currently
transitioning to armel.  From the point of view of building Java stuff
it certainly gets a lot of exercise since pretty much all packages are
built for all architectures.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Building ubuntu/gcc-4_2-branch to get GCJ for arm EABI

[Matthijs van de Water]

I'm not having any luck with GCC 4.3 and I expect to hit more GCC 4.3
problems in OE.
Since the 4.2.3 toolchain seems to build a nicely working root
filesystem without trouble, I'm still very much in favor of using the
Ubuntu-patched GCC 4.2.3.

Matthias Klose (gcc maintainer for Debian/Ubuntu) says that the 4.2.3
Ubuntu version should produce runnable binaries (e.g. testsuite runs
without error), so there must be something wrong in my particular
build.

Is anyone (Robert?) willing to run a build and test a hello world so
we can see if the error is consistent or specific for my build
environment/target hardware?
I've put my current bb-files on http://www.matthijs.net/gcc/ including
patches dir (in tar.gz).

Thanks,
Matthijs