[Bug java/28531] New: [win32] serialisation is broken on mingw (works on linux)

[mtrudel at gmx dot ch]

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)

[mtrudel at gmx dot ch]

--- 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=11965&action=view)
Simple serialisation test

A simple serialisation program to reproduce the bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28531

[Bug java/29150] New: [win32] java.library.path broken

[mtrudel at gmx dot ch]

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

[mtrudel at gmx dot ch]

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

[mtrudel at gmx dot ch]

--- 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=12300&action=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

[mtrudel at gmx dot ch]

--- 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=12301&action=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

[mtrudel at gmx dot ch]

--- 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/29150] [win32] java.library.path broken

[mtrudel at gmx dot ch]

--- 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/30607] gcj -I x -C doesn't include x as source dir search patch

[mtrudel at gmx dot ch]

--- 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 bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

--- 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 bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap

[mtrudel at gmx dot ch]

--- 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 java/30673] New: [jni] Different behaviour than a Sun JRE

[mtrudel at gmx dot ch]

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 

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 c/30832] New: [regression] --with-sysroot=foobar wrong handled

[mtrudel at gmx dot ch]

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

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

--- 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 bootstrap/30832] [regression] --with-sysroot=foobar wrong handled

[mtrudel at gmx dot ch]

--- 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 bootstrap/30832] [regression] --with-sysroot=foobar wrong handled

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

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

[mtrudel at gmx dot ch]

--- 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 libgcj/29477] [SJLJ EH] JNI broken with certain libs

[mtrudel at gmx dot ch]

--- Comment #5 from mtrudel at gmx dot ch  2007-02-24 09:04 ---
The problem is that the new SJLJ backtrace algorithm depends on the typical
function entry sequence "pushl %ebp; movl %esp, %ebp". But while they're always
in our compiled Java code, they are mostly optimized away in JNI libs.
Microsoft Visual C++ mostly removes them in optimization mode -Og (and -Ox
which includes -Og), GCC seems to sometimes remove them in -O2 -O3 and -Os
mode. I think -fno-omit-frame-pointer keeps them for GCC, but I didn't test it.

I think this won't be fixed and we just wait until DWARF EH is finally
available for mingw. Should be soon since it already exists but has not yet
been approved/committed.


-- 

mtrudel at gmx dot ch changed:

   What|Removed |Added

Summary|[MinGW] JNI broken with |[SJLJ EH] JNI broken with
   |certain libs|certain libs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29477

[Bug c/31105] New: build broken (trunk rev 122742)

[mtrudel at gmx dot ch]

/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

[mtrudel at gmx dot ch]

--- 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)

[mtrudel at gmx dot ch]

--- 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 java/31223] New: [regression] indirect dispatch not working with static builds

[mtrudel at gmx dot ch]

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(JArray*)':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

[mtrudel at gmx dot ch]

--- 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 java/30591] Cross build fails because native gcj needed to build ecjx

[mtrudel at gmx dot ch]

--- 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 libgcj/31223] [regression] indirect dispatch not working with static builds

[mtrudel at gmx dot ch]

--- 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 libgcj/32619] -static-libgcj includes entire gnu classpath (>30MB executable from 95byte source)

[mtrudel at gmx dot ch]

--- 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/32619] -static-libgcj includes entire gnu classpath (>30MB executable from 95byte source)

[mtrudel at gmx dot ch]

--- 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 java/29772] New: using @sourcelist-file leads to wrong flag creation

[mtrudel at gmx dot ch]

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

[mtrudel at gmx dot ch]

--- 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=12570&action=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

[mtrudel at gmx dot ch]

--- 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=12571&action=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

[mtrudel at gmx dot ch]

--- 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=12572&action=view)
The list for the source files


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29772

[Bug java/29812] env->klass value is not updated during the native calls

[mtrudel at gmx dot ch]

--- 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/28531] [win32] serialisation is broken on mingw (works on linux)

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

--- 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

[mtrudel at gmx dot ch]

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 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/30574] compiling JDK 1.4 bytecode with inner classes fails

[mtrudel at gmx dot ch]

--- 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=12947&action=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

[mtrudel at gmx dot ch]

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 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

[mtrudel at gmx dot ch]

--- 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=12948&action=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