[PING] Windows patches.

[PING] Windows patches.

[Aaron W. LaFramboise]

General Problems

Fix collect2 on Windows: PR gcc/14316
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01172.html
This definitely needs to be in 4.0.  This is a long standing and
extremely annoying bug that primarily affects crosscompilers, but also
-frepo users.  This bug has been fixed in mingw.org GCC's for a long
time; its time that we fix this.  It needs a libiberty maintainer to
approve the pex_read() parts, and someone who can approve the collect2
and config.host parts.

Support weak symbols on PECOFF targets: PR target/18106
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01656.html
This would be very nice for 4.0.  If its going on 4.0, it probably
should be approved sooner than later.  It needs a Windows maintainer.


Bootstrap/Build Problems

debug/17406: ICE while bootstrapping GCC when dwarf2 is enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17406#c9
Anyone who wants to use dwarf2 (which hopefully is everyone) on Windows
will need this patch applied.  It needs a i386 maintainer.

gcc/17832: Fix fixincludes portability problems
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02731.html
The first patch disables building fixincludes for targets where it is
not needed.  This was done previously, but got lost in the fixincludes
transition to toplevel.  It needs a configury maintainer.
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01618.html
The second patch fixes Windows portability problems with fixincludes.
With the above patch, this is primarily important for crosscompilers.
It needs a fixincludes maintainer.

other/17991: Fix two-process fixincludes
http://gcc.gnu.org/bugzilla/attachment.cgi?id=7376&action=view
This fixes two-process fixincludes, which is needed by Windows,
MS-DOS/DJGPP, and BeOS.  It needs a fixincludes maintainer.

libfortran/18103: Fix system header conflict
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01609.html
A system header conflict breaks bootstrap if Fortran is enabled.  It
needs a libgfortran maintainer.

libfortran/18105: Portability fixes in libgfortran
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01171.html
Missing macros and mkstemp() break bootstraps if Fortran is enabled.
This needs a libgfortran maintainer.

libgcj/18104: Fix Java CLASSPATH problem
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02853.html
An incorrect CLASSPATH separator breaks bootstrap if Java is enabled.
This needs a libgcj maintainer.


Thanks,

Aaron W. LaFramboise

Re: [PING] Windows patches.

[Tom Tromey]

>>>>> "Aaron" == Aaron W LaFramboise <aaronavay62@aaronwl.com> writes:

Aaron> libgcj/18104: Fix Java CLASSPATH problem
Aaron> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02853.html
Aaron> An incorrect CLASSPATH separator breaks bootstrap if Java is enabled.
Aaron> This needs a libgcj maintainer.

This is ok, please check it in.  Apologies for missing it the first
time.

You may want/need to patch the test suite as well.  (I didn't look to
see if it is necessary.)

Tom

Re: [PING] Windows patches.

[Aaron W. LaFramboise]

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

Tom Tromey wrote:

> You may want/need to patch the test suite as well.  (I didn't look to
> see if it is necessary.)

I found one place with a CLASSPATH separator in the testsuite.  I've
started a bootstrap/test cycle with it, which might take a while.  Is
this OK, assuming it passes the tests?

Aaron W. LaFramboise


[-- Attachment #2: gcc-mainline-20041025-libjavatest.patch --]
[-- Type: text/plain, Size: 1729 bytes --]

2004-10-25  Aaron W. LaFramboise  <aaronavay62@aaronwl.com>

	* testsuite/lib/libjava.exp (libjava_arguments): Fix CLASSPATH
	separator handling for Windows.

Index: gcc/libjava/testsuite/lib/libjava.exp
===================================================================
RCS file: /cvs/gcc/gcc/libjava/testsuite/lib/libjava.exp,v
retrieving revision 1.59
diff -c -3 -p -r1.59 libjava.exp
*** gcc/libjava/testsuite/lib/libjava.exp	4 Aug 2004 16:49:21 -0000	1.59
--- gcc/libjava/testsuite/lib/libjava.exp	25 Oct 2004 06:56:08 -0000
*************** proc libjava_arguments {{mode compile}} 
*** 332,337 ****
--- 332,338 ----
      global tool_root_dir
      global libgcj_jar
      global libjava_libgcc_s_path
+     global target_triplet
  
      if [info exists LIBJAVA] {
  	set libjava $LIBJAVA;
*************** proc libjava_arguments {{mode compile}} 
*** 370,379 ****
  
      verbose "LD_LIBRARY_PATH = $env(LD_LIBRARY_PATH)"
  
      # Set the CLASSPATH environment variable
!     verbose "CLASSPATH is .:$srcdir/$subdir:$objdir:$libgcj_jar"
      global env
!     set env(CLASSPATH) ".:$srcdir/$subdir:$objdir:$libgcj_jar"
  
      if {$mode == "link"} {
  	global wrapper_file wrap_compile_flags
--- 371,387 ----
  
      verbose "LD_LIBRARY_PATH = $env(LD_LIBRARY_PATH)"
  
+     # Determine CLASSPATH separator
+     if { [string match "i?86-pc-mingw32*" $target_triplet] } {
+ 	set sep ";"
+     } else {
+ 	set sep ":"
+     }
+ 
      # Set the CLASSPATH environment variable
!     verbose "CLASSPATH is .$sep$srcdir/$subdir$sep$objdir$sep$libgcj_jar"
      global env
!     set env(CLASSPATH) ".$sep$srcdir/$subdir$sep$objdir$sep$libgcj_jar"
  
      if {$mode == "link"} {
  	global wrapper_file wrap_compile_flags

Re: [PING] Windows patches.

[Tom Tromey]

>>>>> "Aaron" == Aaron W LaFramboise <aaronavay62@aaronwl.com> writes:

Aaron> 2004-10-25  Aaron W. LaFramboise  <aaronavay62@aaronwl.com>
Aaron> 	* testsuite/lib/libjava.exp (libjava_arguments): Fix CLASSPATH
Aaron> 	separator handling for Windows.

This is basically ok, but could you make one little change?

Aaron>       # Set the CLASSPATH environment variable
Aaron> !     verbose "CLASSPATH is .$sep$srcdir/$subdir$sep$objdir$sep$libgcj_jar"
Aaron>       global env
Aaron> !     set env(CLASSPATH) ".$sep$srcdir/$subdir$sep$objdir$sep$libgcj_jar"
I suggest using join.  Like:

    set env(CLASSPATH) [join [list . $srscdir/$subdir $objdir $libgcj_jar] \
                             $sep]
    verbose "CLASSPATH is $env(CLASSPATH)"

This is easier to read IMO.

Tom

Re: [PING] Windows patches.

[DJ Delorie]

> The first patch disables building fixincludes for targets where it
> is not needed.  This was done previously, but got lost in the
> fixincludes transition to toplevel.  It needs a configury
> maintainer.

Target-specific changes in configury are normally approved by the
target maintainers, not the configury maintainers, as only the target
maintainers know if the change is correct.

Re: [PING] Windows patches.

[Aaron W. LaFramboise]

DJ Delorie wrote:
>>The first patch disables building fixincludes for targets where it
>>is not needed.  This was done previously, but got lost in the
>>fixincludes transition to toplevel.  It needs a configury
>>maintainer.
> 
> Target-specific changes in configury are normally approved by the
> target maintainers, not the configury maintainers, as only the target
> maintainers know if the change is correct.

(The patch was <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00934.html>.)

This patch affects:
  alpha*-*-*vms*
  arm-semi-aof
  hppa1.1-*-osf*
  hppa1.1-*-bsd*, i370-*-opened*
  i[[3456789]]86-*-mingw32*
  *-*-cygwin*
  i[[3456789]]86-moss-msdos
  i[[3456789]]86-*-moss*
  i[[3456789]]86-*-pe
  powerpc-*-eabi
  powerpcle-*-eabi*
  powerpc-*-rtems*

QNX and AVR targets have indicated also that they don't want fixincludes.

For these targets, this patch restores the behavior of fixincludes
builds before it was moved to toplevel.

Does the patch really need to be signed off by all of these maintainers?
 Unless since fixincludes moved to toplevel one of these targets added
fixincludes rules, which is unlikely, there will be no change in
functionality , except for shorter build times, and perhaps the
difference between a currently broken build and a working build.

Aaron W. LaFramboise

Re: [PING] Windows patches.

[DJ Delorie]

> For these targets, this patch restores the behavior of fixincludes
> builds before it was moved to toplevel.
> 
> Does the patch really need to be signed off by all of these maintainers?
>  Unless since fixincludes moved to toplevel one of these targets added

If this is functionality that just got forgotten in the move, it's
probably "obvious enough" to check it in.  Go ahead.

Re: [PING] Windows patches.

[E. Weddington]

Aaron W. LaFramboise wrote:

>DJ Delorie wrote:
>  
>
>>>The first patch disables building fixincludes for targets where it
>>>is not needed.  This was done previously, but got lost in the
>>>fixincludes transition to toplevel.  It needs a configury
>>>maintainer.
>>>      
>>>
>>Target-specific changes in configury are normally approved by the
>>target maintainers, not the configury maintainers, as only the target
>>maintainers know if the change is correct.
>>    
>>
>
>(The patch was <http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00934.html>.)
>
>This patch affects:
>  alpha*-*-*vms*
>  arm-semi-aof
>  hppa1.1-*-osf*
>  hppa1.1-*-bsd*, i370-*-opened*
>  i[[3456789]]86-*-mingw32*
>  *-*-cygwin*
>  i[[3456789]]86-moss-msdos
>  i[[3456789]]86-*-moss*
>  i[[3456789]]86-*-pe
>  powerpc-*-eabi
>  powerpcle-*-eabi*
>  powerpc-*-rtems*
>
>QNX and AVR targets have indicated also that they don't want fixincludes.
>
>  
>

Bug #18151 has been opened for the AVR target to disable fixincludes. 
I'm waiting for maintainer approval.

Eric

Re: [PING] Windows patches.

[Christopher Faylor]

On Sat, Oct 23, 2004 at 02:59:43PM -0500, Aaron W. LaFramboise wrote:
>Support weak symbols on PECOFF targets: PR target/18106
>http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01656.html
>This would be very nice for 4.0.  If its going on 4.0, it probably
>should be approved sooner than later.  It needs a Windows maintainer.

This is ok for trunk.

cgf