Re: Problem with configure when trying to build gcc 5.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/01/17 14:24, David Gressett wrote:
>> Well, okay as an interim measure, but we really need to debug this.
>> Did you run 'mingw-pkg patch'?  In the source or the build tree?
>> If so, what was its (console) output?
> 
> I ran it as you specified in you message in the MinGW list:
> $ cd $HOME/build/gcc-5.3.0-mingw32
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch

Right.  The CWD *must* be set to the top of the source tree while
applying patches; the 'mingw-pkg patch' command *should* use your
specified SRCDIR, to make that so, but ...

> For my next attempt, I removed both copies of 
> .mingw-pkgrc., deleted all the remains of the previous
> attempt from my build directory and did the patch
> and configure steps again.
> 
> This time, I used tee to save the console display and
> stayed to watch the patch step. 
> 
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 patch | tee ../mingw-pkg-patch.log
> 
> the console showed this:
> 
>>>> apply patches
> 
> 
>>>> done.

... this suggests that it didn't; it should have looked like:

|  $ mingw-pkg SRCDIR=../gcc-5.3.0 patch
| 
|  >>> apply patches
| 
|  >>> applying patch: arch/mingw32/01-mingw-w64-brain-damage.patch
|  patching file gcc/config/i386/mingw32.h
|  >>> applying patch: arch/mingw32/02-mingw32-float.h.patch
|  patching file gcc/ginclude/float.h
|  >>> applying patch: arch/mingw32/03-ada-largefile.patch
|  patching file gcc/ada/adaint.c
|  patching file gcc/ada/adaint.h
|  patching file gcc/ada/cstreams.c
|  >>> applying patch: arch/mingw32/04-eh-frame-begin.patch
|  patching file libgcc/config/i386/cygming-crtbegin.c
|  >>> applying patch: arch/mingw32/05-fortran-strings.patch
|  patching file libgfortran/intrinsics/selected_char_kind.c
|  patching file libgfortran/runtime/environ.c
|  patching file libgfortran/runtime/string.c
|  >>> applying patch: arch/mingw32/06-ssp-wincrypt.patch
|  patching file libssp/ssp.c
| 
|  >>> done.

> It completed so quickly that it is obvious that it really did no
> patches,

I doubt if it even found the patch files, relative to the CWD in
the build tree.  The script fragment which deals with patches is
missing a 'cd $SRCDIR' command; I can fix that ... in fact, I've
already done so in my local code base, to get the above output.

> rather than suppressing or redirecting any console output.
> 
> I then did the configure:
> $ mingw-pkg SRCDIR=../../src/gcc-5.3.0 configure | tee ../mingw-pkg-configure.log
> 
> The configure step produced exactly the same results as my previous
> configure, even though there was no .mingw-pkgrc:  The console display
> still announced that it would build java but not ada and the configure
> command line still contained  --build=x86_64-pc-linux-gnu.

Well, it's getting that from somewhere, (and the only place it
should be able to find it is $HOME/.mingw-pkgrc); FWIW, if I run
the 'mingw-pkg configure' command in MSYS, as:

  $ sh -vx `which mingw-pkg` SRCDIR=../gcc-5.3.0 configure 2>&1

(and capture output via 'tee'), I see:

| checking build system type... i686-pc-mingw32
| checking host system type... i686-pc-mingw32
| checking target system type... i686-pc-mingw32

so $build is *not* being set by --build=x86_64-pc-linux-gnu, (or
by an other explicit option), but is correctly auto-detected as
i686-pc-mingw32, (which is as it should be).  However, I'm also
seeing no evidence of *any* configure options be read from the
package specification file ... indeed, I'm seeing evidence of an
MSYS shell bug, which prevents mingw-pkg from even locating the
package specification file:

|  # Ensure we have a PACKAGE name specification; if not, attempt to deduce
|  # a suitable default from the name of the top-level source code directory.
|  #
|    pkgspec_from_srcdir(){
|      pkgspec_$1 $PACKAGE_ABS_SRCDIR
|    }
|    pkgspec_get_name(){
|      IFS=-; set -- `basename "$1"`; value= IFS=
|      for part
|        do case $part in [0-9]*) break;;
|             *) value="$value$IFS$part" IFS=-;;
|           esac
|        done
|      echo "$value"
|    }
|    PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"}
|  pkgspec_from_srcdir get_name
|  +++ pkgspec_from_srcdir get_name
|  +++ pkgspec_get_name /home/keith/gcc-5.3.0
|  +++ IFS=-
|  basename "$1"
|  ++++ basename /home/keith/gcc-5.3.0
|  +++ set -- gcc 5.3.0
|  +++ value=
|  +++ IFS=
|  +++ for part in '"$@"'
|  +++ case $part in
|  +++ value=gcc
|  +++ IFS=-
|  +++ for part in '"$@"'
|  +++ case $part in
|  +++ value=gcc-5.3.0
|  +++ IFS=-
|  +++ echo gcc-5.3.0
|  ++ PACKAGE=gcc-5.3.0
|    test "x$PACKAGE" = x && PACKAGE='<package>'
|  ++ test xgcc-5.3.0 = x

Notice that it has failed to match the 'case [0-9]*)' pattern, as it
should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
should have been just 'PACKAGE=gcc'; contrast the above with correct
behaviour, when run using the dash shell, on my Linux box:

|  # Ensure we have a PACKAGE name specification; if not, attempt to deduce
|  # a suitable default from the name of the top-level source code directory.
|  #
|    pkgspec_from_srcdir(){
|      pkgspec_$1 $PACKAGE_ABS_SRCDIR
|    }
|    pkgspec_get_name(){
|      IFS=-; set -- `basename "$1"`; value= IFS=
|      for part
|        do case $part in [0-9]*) break;;
|             *) value="$value$IFS$part" IFS=-;;
|           esac
|        done
|      echo "$value"
|    }
|    PACKAGE=${PACKAGE-"`pkgspec_from_srcdir get_name`"}
|  + pkgspec_from_srcdir get_name
|  + pkgspec_get_name /home/keith/src/mingw/gcc-build/src/gcc-5.3.0
|  + IFS=-
|  + basename /home/keith/src/mingw/gcc-build/src/gcc-5.3.0
|  + set -- gcc 5.3.0
|  + value= IFS=
|  + value=gcc IFS=-
|  + break
|  + echo gcc
|  + PACKAGE=gcc
|    test "x$PACKAGE" = x && PACKAGE='<package>'
|  + test xgcc = x

(Do note that this is not an MSYS specific bug; if I substitute
bash for dash, on the Linux box, I see the same mishandling of the
case pattern; I'll have to explore possible work arounds).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYbDVVAAoJEMCtNsY0flo/xwEP/j/TDHNlnAB44qjaSwbIYTmH
GMOU2E6j9iML5oU+m01U2KYqYw33JnOcIr8DdafmMrhmaOIzsRPVRM9ZuQ5fYoKo
gluts7Dv1ZPr24UaQwpgSg8ELVFHO6jubHEYbkkijlza47SA/3ow7PVvk1S6Ar68
7cZYIRMsUbz15HYmeS5Jkn9OfWLhW0TW2yOmqM1FHLb8C8gHZxtDPyb3u0z+C1YF
ZmV2JUoS50ybZZprTLsv6Gc6UhnmEA5MIAtV0KA1gCQxWCZqJukNrG/B5gNUZQeI
6vbBWTcsjwZLkr7aot9tG2XMBS4ChoKxnLGDHFw69ZTuvmGM5TiufafPEen+uWYC
8KQChf3SYvVpN8sO6BVOi9O7l3/5CEcfYNiurTajK7Mn0BNyBfWRNbaU2ambs8Ty
kIkQLBMptdMb7pyAsA6kUSBaIJrQ2MKhjtU9eJYV+cWtHNk/ov3/MArgO2wsjYSm
oix87xYzEBgw+SauooDBuFph4iW+D7akpcJHEdILrJUZ7/wD0OBvA2fB8A1WRVVx
F7rL0aAVlFXdGqRLupoaG3BpdAo3Zn2bYPtGrR1z5pcJUOhcm+ikhF5WI2BsYhl5
hIoXnkhQuLOTeul9uW5gr5Co8yEZbHhc3qYIHOXT/MPF1Po8Z800dXB4VG7oTZwc
xtr2p98+JjxeyvH1f3Cv
=W8m0
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot