[Mingw-notify] [ mingw-Bugs-2031691 ] x86-mingw32-build.sh "config.guess: No such file or dir..."

[SourceForge.net <no...@so...>]

Bugs item #2031691, was opened at 2008-07-29 17:35
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2031691&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dave Korn (davek_cygwin)
Assigned to: Nobody/Anonymous (nobody)
Summary: x86-mingw32-build.sh "config.guess: No such file or dir..."

Initial Comment:
Trying to run the build script on a Linux 2.6 x86_64-unknown-linux-gnu host.  Download stage goes fine, stage 1 binutils builds and installs ok, headers build ok, gcc builds and installs ok, then we get to w32api but the script bombs out with an error:

------------------<snip>------------------
make[2]: Nothing to be done for `install'.
make[2]: Leaving directory
`/home/dk/mingw/tmp/mingw-3.4.5/build-gcc/libiberty/testsuite'
make[1]: Leaving directory
`/home/dk/mingw/tmp/mingw-3.4.5/build-gcc/libiberty'

x86-mingw32-build.sh: stage 1: build w32api ...
x86-mingw32-build.sh: line 139: ../config.guess: No such file or directory
x86-mingw32-build.sh: line 139: ../configure: No such file or directory
x86-mingw32-build.sh: unrecoverable error configuring w32api
------------------<snip>------------------

  Without having figured it out yet, there's something wrong in the way that wildcards are used in e.g. setbuilddir:-

------------------<snip>------------------
   137        case $COMPONENT in mingw-runtime | w32api)
   138          setbuilddir ${COMPONENT}-*
   139          $RUN ../configure --prefix="$INSTALL_DIR" --host="$TARGET" \
   140            --build=${BUILD_PLATFORM=`../config.guess`} || die $? \
   141            "$unrecoverable configuring $COMPONENT"
------------------<snip>------------------

... because looking in the build temp dir:

------------------<snip>------------------
[dk@quattro x86-mingw32-build.sh-0.0-20061107-1]$ ls -la ../tmp/mingw-3.4.5/
total 32
drwxr-xr-x   8 dk eng 4096 Jul 29 16:57 .
drwxr-xr-x   3 dk eng 4096 Jul 29 16:52 ..
drwx------  18 dk eng 4096 Jul 29 16:55 binutils-2.17.50-20060716-1-src
drwxr-xr-x   5 dk eng 4096 Jul 29 16:58 build-gcc
drwxr-xr-x  10 dk eng 4096 Dec 12  2005 gcc-3.4.5-20060117-1
drwxr-xr-x   5 dk eng 4096 Aug 30  2006 mingw-runtime-3.10
drwxr-xr-x   4 dk eng 4096 Jul 29 17:00 w32api-*
drwxr-xr-x   4 dk eng 4096 Apr 14  2006 w32api-3.7
[dk@quattro x86-mingw32-build.sh-0.0-20061107-1]$ 
------------------<snip>------------------

it becomes clear that the wildcard isn't actually globbing, it's been used in an mkdir invocation.  Sure enough, config.guess et. al. live in the real w32api-3.7 dir, not the bogus w32api-\* dir, but, since it got created, the cd in setbuilddir finds the matching name and doesn't glob it or go into the right directory.

  I'll try "set -x" and run the whole thing again from scratch to narrow down exactly how/where the dir gets created.  I'm not entirely clear how this ever worked though.


setbuilddir()
# usage: setbuilddir parent [subdir]
#
# Ensure that the directory parent/subdir exists, creating it if
# necessary, then make it the current directory.
{
  mkdir -p $1/${2-build} && cd $1/${2-build}
}

  OK, that makes a bit more sense: if COMPONENT=w32api, then

  setbuilddir ${COMPONENT}-*

becomes

  mkdir -p w32api-*/ && cd w32api/


Hmm, pardon the rather wordy bug report, but I'm thinking aloud here.  It looks to me like the invocation is just plain wrong.  Why only 1 arg when two are expected?




Here's my build log for the settings: shouldn't be anything surprising or relevant among them.

x86-mingw32-build.sh: building i586-pc-mingw32 ...
 selected components: binutils headers gcc w32api mingw-runtime
 selected languages:  c,c++

x86-mingw32-build.sh: required packages ...
 gcc-core-3.4.5-20060117-1-src.tar.gz
 binutils-2.17.50-20060716-1-src.tar.gz
 mingw-runtime-3.10-20060909-1-src.tar.gz
 w32api-3.7-src.tar.gz
 gcc-g++-3.4.5-20060117-1-src.tar.gz

x86-mingw32-build.sh: general build options ...
 --with-gcc
 --with-gnu-as
 --with-gnu-ld
 --disable-nls
 --disable-debug

x86-mingw32-build.sh: GCC specific build options ...
 --enable-threads=win32
 --disable-win32-registry
 --enable-sjlj-exceptions


----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2008-07-30 10:20

Message:
Logged In: YES 
user_id=823908
Originator: NO

> I'm not entirely clear how this ever worked though.
>
> setbuilddir()
> # usage: setbuilddir parent [subdir]
> #
> # Ensure that the directory parent/subdir exists, creating it if
> # necessary, then make it the current directory.
> {
>   mkdir -p $1/${2-build} && cd $1/${2-build}
> }
>
> OK, that makes a bit more sense: if COMPONENT=w32api, then
> 
> setbuilddir ${COMPONENT}-*
>
> becomes
>
> mkdir -p w32api-*/ && cd w32api/

Wrong!  It becomes

  mkdir -p w32api-*/build && cd w32api-*/build

A more pertinent question to ask would be, "why, when w32api-3.7/ exists,
does `setbuilddir w32api-*' not expand to

  mkdir -p w32api-3.7/build && cd w32api-3.7/build

as it should"?  That's how this has worked, flawlessly, for me and for
everyone else who has successfully built a MinGW cross-gcc on their
GNU/Linux host, using this very script.  Your shell should have globbed
this when it parsed the `setbuilddir ${COMPONENT}-*' command line -- it
failed.  In this respect, this is not a bug in the script; it is your
broken shell which is at fault, and you should direct your bug report to
the correct quarter.

However, I do see a possible problem with this function -- if the
temporary build tree is not clean, (in respect of having subdirs for only
one version each individual component present), then the behaviour of this
function call may be undefined.  IIRC, that shouldn't be allowed to happen,
but this much does merit follow-up.

Having said the above, what happens if you modify line 138 to read

  setbuilddir `echo ${COMPONENT}-*`

or

  eval setbuilddir ${COMPONENT}-*

or the command line within the body of `setbuilddir()' to read

  mkdir -p `echo $1`/${2-build} && cd $1/${2-build}

?

One of those workarounds may make the script more robust, when invoked
with a broken shell, such as you appear to be using.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2031691&group_id=2435