Re: [PATCH] Fix mingw32 bootstrap regression.

[Pedro Alves <pedro_alves at portugalmail dot pt>]

Bob Rossi escreveu:
> On Sun, Dec 24, 2006 at 03:32:54PM -0500, Bob Rossi wrote:
> > On Sun, Dec 24, 2006 at 02:24:08PM +0000, Pedro Alves wrote:
> > > 'Bob Rossi' escreveu:
> > > > > cc1 -E -lang-asm -quiet ...
> > > > > xgcc.exe: CreateProcess: No such file or directory
> > > > Why wouldn't gcc be able to find this?
> > > MinGW/native Windows apps don't know a thing about the /home/bobbybrasko
> > > cygwin mount and xgcc should be a MinGW app.
> > > That's why Danny has the following cygwin mount, and he puts the 
> > > sources/builddir there:
> > >
> > > c:\developex on /developex type system (binmode)
> > >
> > > This way, both cygwin and MinGW will resolve the /developex path to the 
> > > same dir.
> > > (/ on the MinGW side will resolve to the root of the current drive.  )
> > Thanks Pedro! That got me further. I have yet another error.
>
> I've narrowed this down further. It's another cygwin/mingw problem.
> Basically, in /developex/gcc/trunk/build/mingw32/libstdc++-v3/include
> the make command 
>   /developex/gcc/trunk/build/./gcc/xgcc -shared-libgcc
>   ...
>   -I/developex/gcc/trunk/build/mingw32/libstdc++-v3/include/mingw32
>   -I/developex/gcc/trunk/build/mingw32/libstdc++-v3/include
>   ...
> fails with,
>   /developex/gcc/trunk/gcc/libstdc++-v3/include/precompiled/stdc++.h:37:19:
>   error: cassert: No such file or directory^M
>   /developex/gcc/trunk/gcc/libstdc++-v3/include/precompiled/stdc++.h:38:18:
>   error: cctype: No such file or directory^M
> ...
>
> If I do an ls -l /developex/gcc/trunk/build/mingw32/libstdc++-v3/include
> which is in the -I section above I see,
>   ...
>   lrwxrwxrwx  1 bobbybrasko None    59 Dec 26 14:59 cassert ->
>   /developex/gcc/trunk/gcc/libstdc++-v3/include/c_std/cassert
>   lrwxrwxrwx  1 bobbybrasko None    58 Dec 26 14:59 cctype ->
>   /developex/gcc/trunk/gcc/libstdc++-v3/include/c_std/cctype
>   ...
>
> Aha! They are symbolic links. I'm pretty sure the mingw compiler doesn't
> know anything about this. Is this another configuration issue or a gcc
> bootstrap bug?
>
> Danny how do you get past this problem? Have you seen this before?


While we are waiting for the correct way to handle this, (if there is
any), you could try one of the attached scripts.
Put one at a time in the PATH before anything else, eg:

put the ln script in /home/bobbybrasko/testscript
and 'export PATH=/home/bobbybrasko/testscript:$PATH'

Then, start the build from scratch on cygwin.

The first script makes ln always fail, so configure will revert
to use cp instead.  This should work, as long as nothing calls
'ln -s' directly in the build system.  If this doesn't work, I would
go as far as saying the build system has a bug.  In that case you could
try the second ln script attached.  It is a quick hack to turn 'ln -s'
invocations into ln (hard links) ones.

Cheers,
Pedro Alves

#!/bin/sh
false

#!/bin/bash
#
# A wrapper for calling stripping the -s and --symlink options from ln invocations.
# Author: Pedro Alves <pedro_alves@portugalmail.pt>
# Version: 0.02
#

ME="`basename $0`"
EXEC_CMD="/usr/bin/ln"

#exec -a "$ME" "$EXEC_CMD" "$@"

TARGET=""
LINK_NAME=""

ARGS=""
while [ -n "$1" ]; do
   arg="$1"
   shift
   case "$arg" in
      -s | --sy*)
         continue
         ;;
      --*s*)
         ;;
      -*s*)
         arg=`echo ${arg} | sed s/s//g`
         ;;
      -*)
         ;;
      *)
         if [ "x$TARGET" = "x" ]; then
           TARGET=$arg
         elif [ "x$LINK_NAME" = "x" ]; then
           LINK_NAME=$arg
         fi
         continue
         ;;
   esac
   ARGS="$ARGS '$arg'"
done

if [ "x$TARGET" != "x" ] && [ "x$LINK_NAME" != "x" ]; then
  DIR=`dirname $LINK_NAME`
  TARGET=$DIR/$TARGET
fi

eval "set -- $ARGS $TARGET $LINK_NAME"

#echo "$EXEC_CMD" "$@"
exec -a "$ME" "$EXEC_CMD" "$@"