FYI: 2 patches for RH 4.1 branch

FYI: 2 patches for RH 4.1 branch

[Tom Tromey]

Just a quick FYI: I'm putting my NetworkInterface and ProcessBuilder
patches on the RH 4.1 branch.  For trunk these are still pending
Windows fixes/tests.

Tom

Re: FYI: 2 patches for RH 4.1 branch

[Mohan Embar]

Hi Tom,

I'm still stuck on this error when trying to build
the cross compiler:

==================================================
gcc -c   -O2 -g0 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -I. -I/datal/gcc/gcc/gcc 
-I/datal/gcc/gcc/gcc/. -I/datal/gcc/gcc/gcc/../include -I/datal/gcc/gcc/gcc/../libcpp/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gcc/gcc/../libdecnumber -I../libdecnumber    -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=
\"/datal/gcc/build/crossgcc/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/datal/gcc/build/crossgcc/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.3.0\" -DDEFAULT_TARGET_MACHINE=\"i686-pc-mingw32\" -DSTANDARD_BINDIR_PREFIX=\"/datal/gcc/build/crossgcc/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" -
DTARGET_SYSTEM_ROOT=\"/datal/gcc/build/crossgcc/sys-root\" -DTARGET_SYSTEM_ROOT_RELOCATABLE  `test "X${SHLIB_LINK}" = "X" || test "no" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
        -I. -I. -I/datal/gcc/gcc/gcc -I/datal/gcc/gcc/gcc/. -I/datal/gcc/gcc/gcc/../include -I/datal/gcc/gcc/gcc/../libcpp/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gcc/gcc/../libdecnumber -I../libdecnumber /datal/gcc/gcc/gcc/cp/g++spec.c)
/datal/gcc/build/crossgcc/i686-pc-mingw32/bin/as: unrecognized option `-Qy'
make[2]: *** [g++spec.o] Error 1
==================================================

For some reason, it's trying to use the cross assembler with
the build compiler :( I haven't really had time to troubleshoot
this, which is why I haven't been responsive with these two
patches. /datal/gcc/build/crossgcc/i686-pc-mingw32/bin/ isn't
in my path, so I don't know why it wants to use this as.

The last time I tried doing this was a day or two ago. Marco:
when was the last time you got and built the trunk?

If this trunk is busted anyway and it's not just my configuration,
I don't see the harm in checking this in. That way I don't have
to regenerate the world and do a full build of the native compiler
just to build my cross compiler.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: FYI: 2 patches for RH 4.1 branch

[Marco Trudel]

Mohan Embar wrote:
> Hi Tom,
> 
> I'm still stuck on this error when trying to build
> the cross compiler:
> 
> ==================================================
> gcc -c   -O2 -g0 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -I. -I/datal/gcc/gcc/gcc 
> -I/datal/gcc/gcc/gcc/. -I/datal/gcc/gcc/gcc/../include -I/datal/gcc/gcc/gcc/../libcpp/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gcc/gcc/../libdecnumber -I../libdecnumber    -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=
> \"/datal/gcc/build/crossgcc/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/datal/gcc/build/crossgcc/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.3.0\" -DDEFAULT_TARGET_MACHINE=\"i686-pc-mingw32\" -DSTANDARD_BINDIR_PREFIX=\"/datal/gcc/build/crossgcc/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" -
> DTARGET_SYSTEM_ROOT=\"/datal/gcc/build/crossgcc/sys-root\" -DTARGET_SYSTEM_ROOT_RELOCATABLE  `test "X${SHLIB_LINK}" = "X" || test "no" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
>         -I. -I. -I/datal/gcc/gcc/gcc -I/datal/gcc/gcc/gcc/. -I/datal/gcc/gcc/gcc/../include -I/datal/gcc/gcc/gcc/../libcpp/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gmp_mpfr/include -I/datal/gcc/gcc/gcc/../libdecnumber -I../libdecnumber /datal/gcc/gcc/gcc/cp/g++spec.c)
> /datal/gcc/build/crossgcc/i686-pc-mingw32/bin/as: unrecognized option `-Qy'
> make[2]: *** [g++spec.o] Error 1
> ==================================================
> 
> For some reason, it's trying to use the cross assembler with
> the build compiler :( I haven't really had time to troubleshoot
> this, which is why I haven't been responsive with these two
> patches.

I'm looking for the second. So you can concentrate on the ProcessBuilder 
one.


> /datal/gcc/build/crossgcc/i686-pc-mingw32/bin/ isn't
> in my path, so I don't know why it wants to use this as.
> 
> The last time I tried doing this was a day or two ago. Marco:
> when was the last time you got and built the trunk?

rev 121'693. But I will do an update today. I'll inform you if it works...


Marco

> If this trunk is busted anyway and it's not just my configuration,
> I don't see the harm in checking this in. That way I don't have
> to regenerate the world and do a full build of the native compiler
> just to build my cross compiler.
> 
> -- Mohan
> http://www.thisiscool.com/
> http://www.animalsong.org/
> 
> 
> 

Re: FYI: 2 patches for RH 4.1 branch

[Marco Trudel]

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

Marco Trudel wrote:
> Mohan Embar wrote:
>
> <snip>
> 
>> /datal/gcc/build/crossgcc/i686-pc-mingw32/bin/ isn't
> in my path, so I don't know why it wants to use this as.
>>
>> The last time I tried doing this was a day or two ago. Marco:
>> when was the last time you got and built the trunk?
> 
> rev 121'693. But I will do an update today. I'll inform you if it works...

Todays svn trunk (rev 122072) works for me (host=linux, target=mingw). 
The only thing I encountered was that mingw seems to have a problem with 
::OUT.
Keith, this is a jdwp thing. So I assume it's one from your changes... I 
attached a patch of my simple workaround. Maybe you can do something better?


Marco

[-- Attachment #2: jdwp-mingw-examplefix.txt --]
[-- Type: text/plain, Size: 985 bytes --]

Index: gnu/classpath/jdwp/JdwpConstants$StepDepth.h
===================================================================
--- gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(revision 122072)
+++ gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(working copy)
@@ -28,7 +28,7 @@
   JdwpConstants$StepDepth();
   static const jint INTO = 0;
   static const jint OVER = 1;
-  static const jint OUT = 2;
+  static const jint OUTT = 2;
   static ::java::lang::Class class$;
 };
 
Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
===================================================================
--- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 122072)
+++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
@@ -889,7 +889,7 @@
 	    }
 	  break;
 
-	case JdwpConstants$StepDepth::OUT:
+	case JdwpConstants$StepDepth::OUTT:
 	  // All we need to do is check the stack depth
 	  if (sinfo->stack_depth > frame->depth ())
 	    handle_single_step (env, sinfo, thread, method, location);

Re: FYI: 2 patches for RH 4.1 branch

[Mohan Embar]

Hi Marco,

>Todays svn trunk (rev 122072) works for me (host=linux, target=mingw). 

Thanks. I'll give it another try.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: FYI: 2 patches for RH 4.1 branch

[Marco Trudel]

Marco Trudel wrote:
> Marco Trudel wrote:
>> Mohan Embar wrote:
>>
>> <snip>
>>
>>> /datal/gcc/build/crossgcc/i686-pc-mingw32/bin/ isn't
>> in my path, so I don't know why it wants to use this as.
>>>
>>> The last time I tried doing this was a day or two ago. Marco:
>>> when was the last time you got and built the trunk?
>>
>> rev 121'693. But I will do an update today. I'll inform you if it 
>> works...
> 
> Todays svn trunk (rev 122072) works for me (host=linux, target=mingw). 
> The only thing I encountered was that mingw seems to have a problem with 
> ::OUT.
> Keith, this is a jdwp thing. So I assume it's one from your changes... I 
> attached a patch of my simple workaround. Maybe you can do something 
> better?
> 
> 
> Marco
> 
> 
> ------------------------------------------------------------------------
> 
> Index: gnu/classpath/jdwp/JdwpConstants$StepDepth.h
> ===================================================================
> --- gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(revision 122072)
> +++ gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(working copy)
> @@ -28,7 +28,7 @@
>    JdwpConstants$StepDepth();
>    static const jint INTO = 0;
>    static const jint OVER = 1;
> -  static const jint OUT = 2;
> +  static const jint OUTT = 2;
>    static ::java::lang::Class class$;
>  };

BTW: Quite a trick one to search the problem in:
   vi gnu/classpath/jdwp/JdwpConstants$StepDepth.h
especially if gnu/classpath/jdwp/JdwpConstants.h exists ;-)


Marco


> Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
> ===================================================================
> --- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 122072)
> +++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
> @@ -889,7 +889,7 @@
>  	    }
>  	  break;
>  
> -	case JdwpConstants$StepDepth::OUT:
> +	case JdwpConstants$StepDepth::OUTT:
>  	  // All we need to do is check the stack depth
>  	  if (sinfo->stack_depth > frame->depth ())
>  	    handle_single_step (env, sinfo, thread, method, location);

Re: FYI: 2 patches for RH 4.1 branch

[Mohan Embar]

Hi Marco,

>Todays svn trunk (rev 122072) works for me (host=linux, target=mingw). 

Could you send me your configure and build scripts for (lin,win)? I still keep
having problems.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: FYI: 2 patches for RH 4.1 branch

[Marco Trudel]

Mohan Embar wrote:
> Hi Marco,
> 
>> Todays svn trunk (rev 122072) works for me (host=linux, target=mingw). 
> 
> Could you send me your configure and build scripts for (lin,win)? I still keep
> having problems.

Here the relevant GCJ parts:

export 
PATH=/home/Marco/Desktop/compile-bin:/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/bin:$PATH

# compile-bin contains ecj1 and gjavah. I use binutils 2.16.91

cd /home/Marco/Desktop/compile-lin-win/gcc-build
/usr/local/src/gcc/configure 
--prefix=/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win 
--with-sysroot=/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/sys-root 
--build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu 
--target=i686-pc-mingw32 --enable-languages=c,c++,java --enable-libgcj 
--disable-shared --with-gnu-as --with-gnu-ld --disable-nls 
--disable-debug --disable-checking --enable-threads=win32 
--disable-win32-registry --enable-java-gc=boehm 
--enable-java-maintainer-mode 
--with-gmp=/home/Marco/Desktop/compile-lin-win/gmp-out 
--with-mpfr=/home/Marco/Desktop/compile-lin-win/mpfr-out 
--enable-sjlj-exceptions 
--with-build-sysroot=/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/sys-root 



Hope it helps...
Marco

jdwp build failure

[Marco Trudel]

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

Hey all

I pointed this out already last week but maybe it slipped under or got 
forgotten (or I'm just too impatient):
jdwp currently causes a build error since "OUT" seems to be reserved for 
something else or whatever. In any case, I just renamed it to OUTT and 
the build works again.

Keith, this is your field as far as I noticed on the mailinglist. Can 
you give it a meaningful name and commit?


thanks
Marco

[-- Attachment #2: jdwp-mingw-examplefix.txt --]
[-- Type: text/plain, Size: 986 bytes --]

Index: gnu/classpath/jdwp/JdwpConstants$StepDepth.h
===================================================================
--- gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(revision 122072)
+++ gnu/classpath/jdwp/JdwpConstants$StepDepth.h	(working copy)
@@ -28,7 +28,7 @@
   JdwpConstants$StepDepth();
   static const jint INTO = 0;
   static const jint OVER = 1;
-  static const jint OUT = 2;
+  static const jint OUTT = 2;
   static ::java::lang::Class class$;
 };
 
Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
===================================================================
--- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 122072)
+++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
@@ -889,7 +889,7 @@
 	    }
 	  break;
 
-	case JdwpConstants$StepDepth::OUT:
+	case JdwpConstants$StepDepth::OUTT:
 	  // All we need to do is check the stack depth
 	  if (sinfo->stack_depth > frame->depth ())
 	    handle_single_step (env, sinfo, thread, method, location);

Re: jdwp build failure

[Mohan Embar]

Hi Marco,

>jdwp currently causes a build error since "OUT" seems to be reserved for 
>something else or whatever. In any case, I just renamed it to OUTT and 
>the build works again.

I haven't looked into this much, but if the Linux folks aren't
having a problem with this, I'm suspecting a Win32 macro
which is colliding with OUT. Just a guess, though.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: jdwp build failure

[Tom Tromey]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

>> jdwp currently causes a build error since "OUT" seems to be reserved for 
>> something else or whatever. In any case, I just renamed it to OUTT and 
>> the build works again.

Mohan> I haven't looked into this much, but if the Linux folks aren't
Mohan> having a problem with this, I'm suspecting a Win32 macro
Mohan> which is colliding with OUT. Just a guess, though.

It would be nice to know where this conflict comes from.
Sometimes a '#undef OUT' in win32.h can help...
But if we have to we can rename the field.

Tom

Re: jdwp build failure

[Mohan Embar]

Hi All,

>Mohan> I haven't looked into this much, but if the Linux folks aren't
>Mohan> having a problem with this, I'm suspecting a Win32 macro
>Mohan> which is colliding with OUT. Just a guess, though.

>It would be nice to know where this conflict comes from.
>Sometimes a '#undef OUT' in win32.h can help...
>But if we have to we can rename the field.

I had already tried that, but it didn't work. I had even put an
#undef OUT in the offending .cc file with no luck. Still, if it
only happens on Win32, it has to be a macro, right?.
I've only made half-hearted attempts here.  Marco? Otherwise, I'll
try to look at it sometime tomorrow.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: jdwp build failure

[Marco Trudel]

Mohan Embar wrote:
> Hi All,
> 
>> Mohan> I haven't looked into this much, but if the Linux folks aren't
>> Mohan> having a problem with this, I'm suspecting a Win32 macro
>> Mohan> which is colliding with OUT. Just a guess, though.
> 
>> It would be nice to know where this conflict comes from.
>> Sometimes a '#undef OUT' in win32.h can help...
>> But if we have to we can rename the field.
> 
> I had already tried that, but it didn't work.

Works for me if I put it in the header.

I just took a look at the preprocessed output without the undef:
   case JdwpConstants$StepDepth::OUT: becomes
   case JdwpConstants$StepDepth:::

while others like
   case JdwpConstants$StepDepth::StepDepth:

stay unchanged. What does that now mean? If "OUT" is used somewhere else 
already, what's the proper action to do? Rename our new "OUT"? Find the 
first "OUT"?


Marco