[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (30MB executable from 95byte source)
--- Comment #5 from mtrudel at gmx dot ch 2007-07-05 07:03 --- With -Wl,-Map,/tmp/TheLinkMap.txt you get a list of the objects that have been included from libgcj.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (30MB executable from 95byte source)
--- Comment #3 from mtrudel at gmx dot ch 2007-07-04 06:59 --- This is an old discussion and comes up in the mailinglist regularly. The most promising approach is to explicitly exclude parts of the class library. JNC (http://jnc.mtsystems.ch/) supports excluding the GUI stuff (AWT/Swing) and JCE what already leads to a great size reduction (since these will be pulled into every binary). BTW, here the FAQ entry for your question from the JNC website: Why are the binaries so big? As JNC evolves, it supports more and more classes of the Java API. The problem now is, that the Java API classes are heavily interconnected; a simple Hello World application uses the security manager which uses AWT which uses... Because of this, you will always have a big part of the classlibrary in your binaries. For Java, this is not a problem. Endusers require to have the JVM, thus having all classes anyway. For native compilation, this is a bigger problem because it's not just a bug that can be fixed. The design of Java doesn't fit into the concept of native compilation (concerning the size of binaries). Since JNC 0.9, you can exclude parts of the class library if you don't need them and thus drastically reduce the size of your binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
[Bug libgcj/31223] [regression] indirect dispatch not working with static builds
--- Comment #3 from mtrudel at gmx dot ch 2007-04-28 08:12 --- What do you mean with this? What doesn't work? Is this something recent? At least rev 122'233 seemed ok to me... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31223
[Bug java/30591] Cross build fails because native gcj needed to build ecjx
--- Comment #5 from mtrudel at gmx dot ch 2007-04-25 07:17 --- You write it needs a host version of gcj, your host is i686-pc-linux-gnu and configure looks for i686-pc-linux-gnu-gcj? Seems correct to me? What gcj should be searched for? The only problem I'm currently aware of is that the compilation of ecj.jar uses -findirect-dispatch. This fails for static compilations since indirect-dispatch doesn't work anymore with such compilations since some bc abi (or whatever) changes. It can easily be fixed by modifying libgcj.a.spec. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30591
[Bug java/31223] New: [regression] indirect dispatch not working with static builds
With a static gcj build, target=i686-pc-linux, using -findirect-dispatch to
compile a class will result in this compilation error:
/tmp/cciWx2S5.o: In function `main':ccxsXCuN.i:(.text+0x13): undefined
reference to `_Jv_Compiler_Properties'
:ccxsXCuN.i:(.text+0x30): undefined reference to `JvRunMainName'
/tmp/ccmjyQHx.o: In function `void
Test::main(JArrayjava::lang::String**)':Test.class:(.text+0x2e): undefined
reference to `_Jv_InitClass'
:Test.class:(.text+0x51): undefined reference to `_Jv_ResolvePoolEntry'
/tmp/ccmjyQHx.o: In function `global constructors keyed to
0__ZN4TestC1Ev':Test.class:(.text+0xb6): undefined reference to
`_Jv_RegisterNewClasses'
/tmp/ccmjyQHx.o:(.eh_frame+0x11): undefined reference to `__gcj_personality_v0'
collect2: ld returned 1 exit status
Seen with a host=mingw and host=linux GCJ. This worked with GCJ 4.2.
Workaround:
The problem probably lies in libgcj.spec. In my host=linux and target=linux
libgcj.spec, I have:
*lib: %{static-libgcj:-non_shared} %{s-bc-abi:-lgcj_bc;:-lgcj}
%{static-libgcj:-call_shared} -lm -lpthread -lrt-ldl %(libgcc) %(liborig)
Replacing it with:
*lib: %{s-bc-abi:} -lgcj -lm -lpthread -lrt-ldl %(libgcc) %(liborig)
Will make the compilation work again.
--
Summary: [regression] indirect dispatch not working with static
builds
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mtrudel at gmx dot ch
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31223
[Bug java/31223] [regression] indirect dispatch not working with static builds
--- Comment #1 from mtrudel at gmx dot ch 2007-03-16 12:57 --- This also breaks the build when a static built GCJ is taken for the compilation of ecj.jar (because it's compiled with -findirect-dispatch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31223
[Bug c/31105] New: build broken (trunk rev 122742)
/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/xgcc -B/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/ -B/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I/usr/local/src/gcc/gcc -I/usr/local/src/gcc/gcc/. -I/usr/local/src/gcc/gcc/../include -I/usr/local/src/gcc/gcc/../libcpp/include -I/home/Marco/Desktop/compile-lin-lin/gmp-out/include -I/home/Marco/Desktop/compile-lin-lin/mpfr-out/include -I/usr/local/src/gcc/gcc/../libdecnumber -I../libdecnumber /usr/local/src/gcc/gcc/recog.c -o recog.o cc1: warnings being treated as errors /usr/local/src/gcc/gcc/recog.c: In function 'decode_asm_operands': /usr/local/src/gcc/gcc/recog.c:1558: error: ISO C90 forbids mixed declarations and code /usr/local/src/gcc/gcc/recog.c:1600: error: ISO C90 forbids mixed declarations and code make[3]: *** [recog.o] Error 1 make[3]: Leaving directory `/home/Marco/Desktop/compile-lin-lin/gcc-build/gcc' This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the warnings being treated as errors but most developers don't use this? That would explain why people stumble over it while it seems to work after changes for the developers?! I configured with: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin --with-sysroot=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root --build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++,java --enable-libgcj --disable-shared --with-gnu-as --with-gnu-ld --disable-nls --disable-debug --disable-checking --enable-threads=posix --disable-win32-registry --enable-java-gc=boehm --enable-java-maintainer-mode --with-gmp=/home/Marco/Desktop/compile-lin-lin/gmp-out --with-mpfr=/home/Marco/Desktop/compile-lin-lin/mpfr-out -- Summary: build broken (trunk rev 122742) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug boehm-gc/29476] [cygwin] gcc compilation is broken
--- Comment #3 from mtrudel at gmx dot ch 2007-03-09 14:05 --- I close this bug as WONTFIX because there's no active cygwin maintainer for libjava. So, if it's not fixed already, it probably won't be fixed anyway. I just once tested it for fun :-) -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29476
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #2 from mtrudel at gmx dot ch 2007-03-09 14:12 --- Thanks. But actually I also tried to start a discussion why such compilation errors can happen: This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the warnings being treated as errors but most developers don't use this? That would explain why people stumble over it while compilation seems to work for the developers?! Of course I could be completely wrong. But if I'm right, there would be an easy way to prevent such build breaks... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug bootstrap/30832] [regression] --with-sysroot=foobar wrong handled
--- Comment #8 from mtrudel at gmx dot ch 2007-02-20 10:42 --- Since there seems to be an issue, I would like to reopen this bug but change the summary to: gcc 4.2/4.3: different --with-sysroot handling Although I'm not sure if it actually is a bug, I think it should be attended to. So if there are no objections until tomorrow evening, I'll reopen it (once more). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30832
[Bug java/30903] New: regeneration of headers is broken/difficult
If we delete a .java file the build will crash. Instead we ought to adjust properly. The other related thing that needs fixing is the mess with -M options. -- Summary: regeneration of headers is broken/difficult Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30903
[Bug java/30903] regeneration of headers is broken/difficult
--- Comment #1 from mtrudel at gmx dot ch 2007-02-21 07:59 --- Tom, can you drop me a note when this is done? I then recheck your NetworkInterface re-merge for mingw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30903
[Bug bootstrap/30832] [regression] --with-sysroot=foobar wrong handled
--- Comment #7 from mtrudel at gmx dot ch 2007-02-19 08:25 --- Well, it makes sense that the kernel-source is also needed. But then again, we have four setups: 1. GCC 4.2, build=linux, host=linux, target=linux 2. GCC 4.2, build=linux, host=mingw, target=linux 3. GCC 4.3, build=linux, host=linux, target=linux 4. GCC 4.3, build=linux, host=mingw, target=linux For all, I specify --with-sysroot but not --with-build-sysroot and put glibc and glibc-devel into the specified sysroot. For setup 1, 2 and 4 this works. Only setup 3 is missing linux/limits.h. So, how probable is that we have 3 builds that work although they shouldn't and only one that does the right thing by failing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30832
[Bug c/30832] New: [regression] --with-sysroot=foobar wrong handled
Configuring with: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/manual-test/gcc --with-sysroot=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root --enable-languages=c,c++ --with-gmp=/home/Marco/Desktop/compile-lin-lin/gmp-out --with-mpfr=/home/Marco/Desktop/compile-lin-lin/mpfr-out leads to a failing make: /home/Marco/Desktop/manual-test/build/./gcc/xgcc -B/home/Marco/Desktop/manual-test/build/./gcc/ -B/home/Marco/Desktop/manual-test/gcc/i686-pc-linux-gnu/bin/ -B/home/Marco/Desktop/manual-test/gcc/i686-pc-linux-gnu/lib/ -isystem /home/Marco/Desktop/manual-test/gcc/i686-pc-linux-gnu/include -isystem /home/Marco/Desktop/manual-test/gcc/i686-pc-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/usr/local/src/gcc/libgcc -I/usr/local/src/gcc/libgcc/. -I/usr/local/src/gcc/libgcc/../gcc -I/usr/local/src/gcc/libgcc/../include -I/usr/local/src/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /usr/local/src/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/errno.h:36, from /usr/local/src/gcc/libgcc/../gcc/tsystem.h:96, from /usr/local/src/gcc/libgcc/../gcc/libgcc2.c:33: /home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/bits/errno.h:25:26: error: linux/errno.h: No such file or directory In file included from /home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/bits/posix1_lim.h:153, from /home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/limits.h:145, from /home/Marco/Desktop/manual-test/build/./gcc/include/limits.h:122, from /home/Marco/Desktop/manual-test/build/./gcc/include/syslimits.h:7, from /home/Marco/Desktop/manual-test/build/./gcc/include/limits.h:11, from /usr/local/src/gcc/libgcc/../gcc/tsystem.h:108, from /usr/local/src/gcc/libgcc/../gcc/libgcc2.c:33: /home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root/usr/include/bits/local_lim.h:36:26: error: linux/limits.h: No such file or directory make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/home/Marco/Desktop/manual-test/build/i686-pc-linux-gnu/libgcc' In sysroot, I have glibc and glibc-devel. This worked with gcc 4.2 and with gcc 4.3 for every build, host, target combination except all linux-gnu. The most interesting one is a build=linux host=mingw target=linux where sysroot contains the exactly same files. This, as said already, works... This should work at least because I use --with-sysroot and not --with-build-sysroot. -- Summary: [regression] --with-sysroot=foobar wrong handled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30832
[Bug c/30832] [regression] --with-sysroot=foobar wrong handled
--- Comment #2 from mtrudel at gmx dot ch 2007-02-17 11:30 --- No, for these reasons: - It worked for 4.2 - I would agree if I used --with-build-sysroot - It works with a cross host=mingw target=linux - It doesn't work if I copy the missing headers to sysroot -- mtrudel at gmx dot ch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30832
[Bug c/30832] [regression] --with-sysroot=foobar wrong handled
--- Comment #4 from mtrudel at gmx dot ch 2007-02-17 12:23 --- Update: It works if I copy the kernel-headers into $SYS_ROOT/usr/include instead of $SYS_ROOT/include. However, I really think this should not be required since it worked with gcc 4.2 and everything else is the same. So either it was a catastrophic build error on 4.2 and miracle that the compiled gcc worked (without linux/limits.h) or it's a regression now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30832
[Bug java/30673] New: [jni] Different behaviour than a Sun JRE
A JNI problem where GCJ isn't doing the same as a Sun JDK:
public class NativeBooleanTest
{
public static void main(String[] args)
{
System.loadLibrary(nativeBoolean);
nativePrintBoolean(false);
nativePrintBoolean(true);
nativePrintBooleanAsInt(false);
nativePrintBooleanAsInt(true);
}
private static native void nativePrintBoolean(boolean b);
private static native void nativePrintBooleanAsInt(boolean b);
}
C code:
#include jni.h
JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBoolean
(JNIEnv *env, jclass c, jboolean b)
{
printf(nativePrintBoolean: %d\n, b);
}
JNIEXPORT void JNICALL Java_NativeBooleanTest_nativePrintBooleanAsInt
(JNIEnv *env, jclass c, jint b)
{
printf(nativePrintBooleanAsInt: %d\n, b);
}
On a sun JVM, the output will be:
nativePrintBoolean: 0
nativePrintBoolean: 1
nativePrintBooleanAsInt: 0
nativePrintBooleanAsInt: 1
GCJ will print something like:
nativePrintBoolean: 0
nativePrintBoolean: 1
nativePrintBooleanAsInt: 10084864
nativePrintBooleanAsInt: 10084865
--
Summary: [jni] Different behaviour than a Sun JRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mtrudel at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30673
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #20 from mtrudel at gmx dot ch 2007-01-31 16:19 --- In case it helps; I use this configuration on my 32bit Linux box to configure: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/gcc --build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++,java --enable-libgcj --with-gnu-as --with-gnu-ld --disable-nls --disable-debug --disable-checking --enable-threads=posix --disable-win32-registry --with-gmp=/home/Marco/Desktop/gmp-out --with-mpfr=/home/Marco/Desktop/mpfr-out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #17 from mtrudel at gmx dot ch 2007-01-30 10:52 --- Has there been any progress with this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #18 from mtrudel at gmx dot ch 2007-01-30 11:00 --- Sorry, the previous message has been truncated: Has there been any progress with this bug? I can confirm it and I need the mentioned patch to be able to compile the current trunk: - tree bases; + tree bases = NULL_TREE; I understand that some configurations work and some fail. Also I cannot confirm the depency of bug 30549 since 30549 was fixed and this one still occurs... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug libgcj/30638] Dummy bug to test gcj Bugzilla
--- Comment #5 from mtrudel at gmx dot ch 2007-01-30 17:33 --- I do not even understand all German words although it's my mother tongue... So how should I translate it to Italian??? ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30638
[Bug java/21695] ICE when building gnu-xml.lo in libjava directory
--- Comment #3 from mtrudel at gmx dot ch 2007-01-30 21:44 --- Yes, mingw worked at least for revision 121232. But the report was for cygwin. Cygwin is broken anyway I think... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
[Bug java/30607] gcj -I x -C doesn't include x as source dir search patch
--- Comment #1 from mtrudel at gmx dot ch 2007-01-27 10:12 --- I can confirm that. However, I don't know if it's a bug or just luck that it worked before. I think the correct command would be: gcj -C -Ix x/a.java (no space between -I and x) This way it works and I think (I'm absolutely not sure) this is the official way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug java/30574] compiling JDK 1.4 bytecode with inner classes fails
--- Comment #1 from mtrudel at gmx dot ch 2007-01-24 14:03 --- Created an attachment (id=12947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12947action=view) The source of the simple class... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30574
[Bug java/30574] New: compiling JDK 1.4 bytecode with inner classes fails
Compiling the bytecode of a class with an inner class that was compiled with a Sun JDK 1.4 fails: $ gcj4.3 -c *.class -o test.o FailingClass.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. But gcj4.2 -c *.class -o test.o works, so I guess this is a regression. It works when the class is compiled with GCJ itself or a Sun JDK 1.5 or 1.6... -- Summary: compiling JDK 1.4 bytecode with inner classes fails Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30574
[Bug java/30574] compiling JDK 1.4 bytecode with inner classes fails
--- Comment #2 from mtrudel at gmx dot ch 2007-01-24 14:05 --- Created an attachment (id=12948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12948action=view) The bytecode from a Sun JDK 1.4. Compiling this with a 4.3 gcj fails... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30574
[Bug java/28531] [win32] serialisation is broken on mingw (works on linux)
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:13 --- Fixed in 4.3 mainline. The gcj specific serialization was replaced with the classpath serialization (StackWalker or something). Thanks guys... minGW gets better and better :-) -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
[Bug libgcj/29151] [win32] Runtime.exec(String[] cmdarray, String[] envp) - envp doesn't work
--- Comment #4 from mtrudel at gmx dot ch 2007-01-20 10:16 --- I thought this was already closed? Well, Mohan fixed it. It is in the 4.2 branch and in the 4.3 mainline (trunk)... Thank you Mohan! -- mtrudel at gmx dot ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/30515] New: mixing source (.java) and bytecode (.class) no longer works with gcj 4.3
gcj -s -O2 --main=HelloWorld HelloWorld.java World.class -o foobar.exe Works with gcj 4.2 but fails with gcj 4.3: C:\DOKUME~1\Marco\LOKALE~1\Temp/ccSkeaaa.o:ccoFcaaa.jar:(.text+0x66): undefined reference to `java::lang::String* World::getWorld()' collect2: ld returned 1 exit status also: gcj -s -O2 --main=HelloWorld HelloWorld.java World.class -ofoobar.exe (No space between -o and foobar.exe). That works with gcj 4.2 and the no space thing with gcj 4.3 usually too. But in this case, when compilation would fail anyway, it gives an internal compiler error: C:\DOKUME~1\Marco\LOKALE~1\Temp/ccgrbaaa.jar:0: internal compiler error: in java_parse_file, at java/jcf-parse.c:1945 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. It's not really clear if it is a regression or if it was just luck that it worked before. It is, however, very useful to be able to compile mixed source and I actually run into trouble a couple of times already because of this. So I'd go for fixing this :-) The see the discussion here: http://gcc.gnu.org/ml/java/2007-01/msg00101.html -- Summary: mixing source (.java) and bytecode (.class) no longer works with gcj 4.3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30515
[Bug java/29812] env-klass value is not updated during the native calls
--- Comment #1 from mtrudel at gmx dot ch 2006-11-13 18:48 --- Why do you make a bugreport if there's already a fix for that? Did no one reply to your patch or don't you have copyright assignment? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29812
[Bug java/29772] New: using @sourcelist-file leads to wrong flag creation
Create a dir named foo bar. Put the attached HelloWorld.java, HelloWorld2.java and source.txt in it. source.txt has this two lines: foo\ bar/HelloWorld.java foo\ bar/HelloWorld2.java Change to the parent folder and type: gcj --main=HelloWorld -o HelloWorld @foo bar/source.txt It will fail with: foo:0: warning: duplicate class will only be compiled once fatal error: can't open foo: No such file or directory compilation terminated. It will work when: - -o is omitted - the space between -o and HelloWorld is removed: gcj --main=HelloWorld -oHelloWorld @foo bar/source.txt - the files in source.txt have no spaces - when only one file is in source.txt (with spaces) -- Summary: using @sourcelist-file leads to wrong flag creation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: independent GCC host triplet: independent GCC target triplet: independent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #1 from mtrudel at gmx dot ch 2006-11-08 21:54 --- Created an attachment (id=12570) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12570action=view) A sample source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #2 from mtrudel at gmx dot ch 2006-11-08 21:54 --- Created an attachment (id=12571) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12571action=view) A second sample source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29772] using @sourcelist-file leads to wrong flag creation
--- Comment #3 from mtrudel at gmx dot ch 2006-11-08 21:55 --- Created an attachment (id=12572) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12572action=view) The list for the source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772
[Bug java/29150] [win32] java.library.path broken
--- Comment #2 from mtrudel at gmx dot ch 2006-10-10 21:20 --- Fixed... The path separator was set to : on all platforms instead of ; for windows. -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug java/29150] New: [win32] java.library.path broken
While passing -Djava.library.path=foobar to GCJ leads to the expected behaviour on linux, it seems to be ignored on windows. Actually System.getProperty(java.library.path) returns the correct value on both plattforms, but System.loadLibrary() only uses it on linux. -- Summary: [win32] java.library.path broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug java/29151] New: [win32] Runtime.exec(String[] cmdarray, String[] envp) - envp doesn't work
Runtime.exec(String[] cmdarray, String[] envp) doesn't set the environment on windows but it works on linux. This can be reproduced with the attached files (both compiled to executables and CreateEnv calling PrintEnv). -- Summary: [win32] Runtime.exec(String[] cmdarray, String[] envp) - envp doesn't work Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/29151] [win32] Runtime.exec(String[] cmdarray, String[] envp) - envp doesn't work
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:32 --- Created an attachment (id=12300) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12300action=view) Program that uses Runtime.exec(...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/29151] [win32] Runtime.exec(String[] cmdarray, String[] envp) - envp doesn't work
--- Comment #2 from mtrudel at gmx dot ch 2006-09-20 16:33 --- Created an attachment (id=12301) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12301action=view) Program that gets called by Runtime.exec(...) and doesn't have the environment set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/29150] [win32] java.library.path broken
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:49 --- Tom commented this on the mailing list. Might be useful: Offhand I would expect this to work ok. You might verify that USE_LTDL is set on Windows; see the two definitions of _Jv_SetDLLSearchPath in natSystemProperties.cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug java/28531] New: [win32] serialisation is broken on mingw (works on linux)
gcj (GCC) 4.2.0 20060726 (experimental) Deserialize an object fails on Class.forName(). I assumed this would work because class.forName() doesn't use the stack unwinder any longer. Exception: Exception in thread main java.lang.ClassNotFoundException: Serialisation at java.lang.Class.forName(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/lang/natClass.cc:91) at java.io.ObjectInputStream.resolveClass(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:800) at java.io.ObjectInputStream.readClassDescriptor(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:551) at java.io.ObjectInputStream.readObject(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:245) at java.io.ObjectInputStream.readObject(/home/trudemar/.eclipse_workspace/gcjSource/libjava/java/io/ObjectInputStream.java:292) at Serialisation.read(D:/programming/javaCompiler/code/tests/1_console/2_serialisation/Serialisation.java:43) at Serialisation.main(D:/programming/javaCompiler/code/tests/1_console/2_serialisation/Serialisation.java:21) -- Summary: [win32] serialisation is broken on mingw (works on linux) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
[Bug java/28531] [win32] serialisation is broken on mingw (works on linux)
--- Comment #1 from mtrudel at gmx dot ch 2006-07-29 13:38 --- Created an attachment (id=11965) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11965action=view) Simple serialisation test A simple serialisation program to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531
