Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Upstream explanation is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712

Basically you need to either put ftp://sourceware.org/pub/java/ecj-latest.jar
as ecg.jar in /var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0 before
calling GCC 4.3's configure or use --with-ecj-jar=filename option...

In this case GCC 4.3 will create useful
/usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/ecj1 and GCJ will work. If ecj.jar is
not found at compilation time then it's up to user to provide ecj1 in $PATH...

(In reply to comment #0)
> Upstream explanation is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
> 
> Basically you need to either put ftp://sourceware.org/pub/java/ecj-latest.jar
> as ecg.jar in /var/tmp/portage/sys-devel/gcc-4.3.0/work/gcc-4.3.0 before
> calling GCC 4.3's configure or use --with-ecj-jar=filename option...
> 
> In this case GCC 4.3 will create useful
> /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/ecj1 and GCJ will work. If ecj.jar is
> not found at compilation time then it's up to user to provide ecj1 in $PATH...
> 

Adding
cd ${WORKDIR}/${P}/contrib && ./download_ecj
last in src_unpack() and adding net-ftp/ftp as a dep. to gcj fixes this( I
think, still compiling... ). I imagine there's a better way then the
download_ecj and the ftp dep. it requires, but it's the GCC way of doing it.
Maybe, 
wget ftp://sourceware.org/pub/java/ecj-latest.jar -O
${WORKDIR}/${P}/contrib/ecj.jar
is nicer. I'm new to all this :)

Oops, ecj.jar should go in top-dir. So, (with ftp)
cd ${WORKDIR}/${P} && ./contrib/download_ecj
or
wget ftp://sourceware.org/pub/java/ecj-latest.jar -O ${WORKDIR}/${P}/ecj.jar

Yes, this hack will work (I did something similar), but it's not a good
long-term solution. What happens if later
ftp://sourceware.org/pub/java/ecj-latest.jar will be changed and will only work
with gcc 4.10 or something like this? It's create a mess. To fix it properly
this file should be mirrored somewhere (probably on Gentoo mirrors) under sane
name (something like ecj-20070727.jar), then it should be downloaded as normal
file and put in proper place at src_unpack stage.

*** Bug 225605 has been marked as a duplicate of this bug. ***

maintaining any java stuff in gcc is undesirable

java team: can you update dev-java/eclipse-ecj so as to provide an `ecj1`
symlink ?

I stumbled upon this report while tyring to build "pdftk".

Following the suggestions found here, I have installed
dev-java/eclipse-ecj and created a symlink from /usr/bin/ecj1 to
/usr/bin/ecj-3.3. However, I have not rebuilt gcc because it takes
"forever".

Building the" pdftk" fails with

>>> Compiling source in /var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/pdftk ...
make -C ../java_libs
make[1]: Entering directory
`/var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/java_libs'
make -C
"/var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/java_libs/gnu_local/java/security";
make[2]: Entering directory
`/var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/java_libs/gnu_local/java/security'
gcj -march=k8 -O2 -pipe --encoding=UTF-8
--classpath="/var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/java_libs" -c
Engine.java -o E
ngine.o
/usr/lib64/portage/pym/portage_dep.py:39: DeprecationWarning: DEPRECATION
NOTICE: The portage_dep module was replaced by portage.dep
Unrecognized option :
-fbootclasspath=/var/tmp/portage/app-text/pdftk-1.41/work/pdftk-1.41/java_libs/:/usr/share/gcc-data/x86_64-pc-linux
-gnu/4.3.1/java/libgcj-4.3.1.jar

Should I rebuild gcc?

Given my time constraints, and the fact that the problem has been
introduced with gcc version 4.3, I circumvented this problem by
reverting to the earlier version of gcc installed on my system, namely
version 3.4.4.

Unfortunately, this version of gcc was hard masked so I could not
emerge gcc version 3.4.4.. The solution was to find an unmasked
version earlier than version 4.3 but later than version 3.4.4.

Here is how I did it:

> emerge -pv '<sys-devel/gcc-4'
[ebuild   R   ] sys-devel/gcc-3.4.6-r2  USE="fortran gcj nls (-altivec)
-bootstrap -boundschecking -build -d -doc -gtk (-hardened) -ip28 -ip32r10k
-libffi (-multilib) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -test
-vanilla" 0 kB

> USE="gcj" emerge '=sys-devel/gcc-3.4.6-r2'

I also followed the directions for upgrading GCC [1].

HTH,

[1] http://www.gentoo.org/doc/en/gcc-upgrading.xml

I have maked it work.

1. emerge eclips-ecj
2. sudo vim /usr/bin/ecj1
 and where change
gjl_main="org.eclipse.jdt.internal.compiler.batch.Main"
to
gjl_main="org.eclipse.jdt.internal.compiler.batch.GCCMain"

Know someone from where ecj1 come from?

contrib/download_ecj is the acknowledged way of fulfilling this dependency by
upstream.  Hence others will depend on it so the jar file is hardly going to
move.  But if you think it's a problem, then you should discuss it with them
rather than complaining here.

As to 'maintaining any java stuff in gcc is undesirable', it's part of gcc so
get over it.

Having an ecj1 symlink won't cut it completely, the build also needs to be
supplied with a copy of ecj.jar.  By far the easiest way to do this is to patch
gcc-4.3.1 to download ecj as upstream specifies.

I've put the patched version in the java-overlay for now but this isn't a
permanent solution.  Please fix gcc.

Tom Tromey has kindly made the ecj-latest.jar into a symlink which currently
points to ecj-4.3.jar.

ftp://sourceware.org/pub/java/

So now the Gentoo ebuild can rely on this version for 4.3

I've made the ebuild in java-overlay slightly less evil. No one likes using
wget during src_unpack.

I couldn't get this to work, not manually and not with the ebuilds from the
java overlay. So I resorted to emerging gcc 4.2 in a separate slot (gcc-4.2
with gcj useflag, gcc-4.3 without), and symlinked gcj and gcjh to the 4.2
version. With this I can emerge "pdftk" again. Not sure if mixing gcc-4.2 and
4.3 like this is a good idea in general. Would love to see a proper fix for
gcc-4.3.

What was the problem though?

The problem is the current build of gcj is unusable -- it can't compile
anything.

No, I meant what was the problem that Andreas had with the ebuilds from the
overlay?

I'm completely lost with this ecj1...

I have no /usr/bin/ecj1 and I'm getting (dev-java/eclipse-ecj-3.4-r2):
>>> Unpacking ecjsrc-3.4.zip to /var/tmp/portage/portage/dev-java/eclipse-ecj-3.4-r2/work
 * bootstrapping ecj with /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1/gcj -C ...
gcj: error trying to exec 'ecj1': execvp: Permission denied

for hello.java:
gcj: error trying to exec 'ecj1': execvp: No such file or directory

I have /usr/bin/ecj with "...batch.Main", so when I create symlink for ecj1:
 * bootstrapping ecj with /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1/gcj -C ...
Unrecognized option :
/var/tmp/portage/portage/dev-java/eclipse-ecj-3.4-r2/temp//ccnGH4Tajx

for hello.java:
invalid debug option: -g1

When I change gjl_main to "...batch.GCCMain":
 * bootstrapping ecj with /usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1/gcj -C ...
java.lang.ArrayIndexOutOfBoundsException: -1
        at
org.eclipse.jdt.internal.compiler.parser.Parser.consumeFieldAccess(Parser.java:3492)
        at
org.eclipse.jdt.internal.compiler.parser.Parser.consumeRule(Parser.java:5688)
        at
org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9007)
        at
org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9238)
        at
org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9195)
        at
org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java:7851)
        at
org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:587)
        at
org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:357)
        at
org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:371)
        at
org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3410)
        at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1607)
        at
org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(GCCMain.java:475)
        at
org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:492)

for hello.java - nothing, and no hello executable or anything else.

Java VM: sun-jdk-1.6
ecj: ecj-3.3
gcc: 4.3.1-r1
COMPILERS="javac ecj-3.3 jikes"

My ecj1 is at /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.1/ecj1, which is where
it should be. You definitely used gcc from the overlay, right?

This has been fixed in the tree.  Thanks all.

Thanks for doing this.  Just for the record, ecj.jar was not removed, it's a
new external dependency from gcc 4.3 onwards.

(In reply to comment #21)
> This has been fixed in the tree.  Thanks all.
> 

When or where is the new ebuild available? (not yet in the standard
emerge 2008/09/02)

Please consider revbumping as we still get bug reports about this from people
who didn't recompile gcc after the fix.

*** Bug 236398 has been marked as a duplicate of this bug. ***

my gcc is still failing, needs a revdump? seems i'm running the latest one

after re-emerging it works.
looks fixed in the portage tree

gcc 4.3.2 is now in the tree, so everyone will be getting that version now
anyway.