Message-ID: <49817A58.2080507@cwilson.fastmail.fm>
Date: Thu, 29 Jan 2009 04:43:52 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RFD: cygwin + *native* MinGW compiler
References: <BEBA87DEFCC94625AFD40845D6E627FE AT THOMAS>
In-Reply-To: <BEBA87DEFCC94625AFD40845D6E627FE@THOMAS>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Danny Smith wrote:
> The reasons I use "--build=mingw32 --host=mingw32 --target=mingw32" 
> when building gcc are
> 1) I have, perhaps mistakenly, assumed that "--build=" referred to the OS of the compiler,
> not the ethnicity of the shell.

I've assumed it was describing the entire build environment: compiler,
yes, linker, yes, but also the surrounding utilities involved in the
configuration/compilation process. That's why config.guess uses uname,
not $CC -version.

I guess that's the nub of the discussion we're having right now: what
does it mean when the $build compiler/toolchain is A, but all the other
$build tools are B? In seems fragile to assume /either/ build==A, /or/
build==B.

> 2) my build gcc is a mingw32 gcc, and unlike a cygwin-hosted gcc, doesn't understand
> symlinks.  "--build=cygwin32"  would suggest that the native gcc understands symlinks.
> Ditto for my binutil and gdb apps which do not depend on cygwin.

Good point. See next para.

> 3) specifying "--host=mingw32 --target=mingw32" usually works just fine too (within a
> cygwin bash shell), for most projects, as long as there are no assumptions about symlinks.

Hmmm. When you specify host and target (obviously we're now talking
about configuring/building a compiler or part of a compiler toolchain,
and not simply Q.Random.Utility.Package; those don't have --target),
$build is set implicitly by analyzing the current OS (c.f. config.guess,
uname, etc).  So, in effect, you're saying that --build=cygwin
--host=mingw32 --target=mingw32 works?

Again hmmm. So that must mean that (legions of slaving GCC developers)
have already set things up in the gcc tree so that symlinks aren't
used...ever? Even when $build supports them?

> 4) "--build=mingw32 --host=mingw32 --target=mingw32"  always seemed to be a natural way to
> do a bootstrap.

Certainly. If *everything* about the build environment was, in fact,
"mingw" (or, actually, msys in its normal "don't mind me; I'm
mingw...really, I am!" mode).

But when the toolchain is mingw, but the rest of the $build env is
cygwin? Not quite so natural.

> I don't set any special environment variables before I "bash ./config.sh" from a DOS
> prompt (my everday path just put C:/mingw/bin in front of C:/cygwin/bin) and I don't cross
> my fingers because I know it has worked for 10 years or so.

Yes, I know: you're one of the first people I thought of when this
subject came up on the libtool list. I *really* want to make sure that
things keep working for you, in the way you expect them to (with maybe
only a small tweak to your build.sh <g>)

But I worry that things are (or will soon be) broken already.  gcc
currently has a snapshot of development libtool from 2007-03-18, with
several fixes backported from more recent git. So, presently, the
libtool used by gcc does the following, when building an exe that
depends on an uninstalled shared library [*]:
 1) creates both a wrapper script foo and wrapper exe foo.exe in the
build directory, and also (?) a copy of the wrapper script in .libs/
 2) the wrapper exe execs the wrapper script via $SHELL
 3) the wrapper script handles all the $PATH manipulations, and
locates/execs the "real" exe

[*] Doesn't this description apply to most of the tools, and many of the
testsuite apps?  Now, if libtool is only used to build the libs, and
gcc's Makefiles/test harnesses handle everything else without the use of
libtool or its wrapper script/wrapper exe system...then whew! maybe we
dodged a bullet!

[**] Note the context switches involved in old libtool (current gcc
libtool): you're in $build, and you launch the $host wrapper exe, which
launches the $build $SHELL, which executes the wrapper script in a
$build context, which launches the $host "real" exe.

This 1-2-3 step process works fine in all the scenarios mentioned;
mainly because the "difficult bits" are handled by $SHELL (of whatever
flavor) and its underlying runtime (be it cygwin [***], or msys[****],
or whatever).

[***] cygwin's exec() implementation translates many environment
variables from posix to win32 format, when the target of the exec() is a
non-cygwin application. So, when //bash// execs the real exe, under the
hood cygwin translates $PATH. Also, cygwin's exec() implementation
translates the unix path-to-real.exe before (eventually) invoking
CreateProcess with a win32 path-to-real.exe.

[****] msys's bash works similarly to cygwin, expecially its interaction
with the underlying posix dll's exec implementation.

But...this 1-2-3 process never worked in cygwin-1.5 if
CYGWIN=transparent_exe (more at the link, below).

However, in cygwin-1.7 this has significant problems; the old (optional)
transparent_exe behavior is now the default. This means that having both
a wrapper script 'foo' and a wrapper exe 'foo.exe' in the same directory
 is very bad news.
See this thread:
libtool vs. transparent_exe [Was: [ITP] util-linux]
http://sources.redhat.com/ml/cygwin/2006-03/msg00148.html

And this one a year later:
.exe magic
http://sources.redhat.com/ml/cygwin/2007-04/msg00515.html

Which eventually led to the behavior that libtool 2.2.0+ exhibits: it
now generates only the wrapper .exe (there's still a version of the
wrapper script in .libs/, but that's only used internally by libtool --
"sourced" back in). The wrapper .exe now directly execs the "real"
executable -- and manipulates **env itself.  However:

The wrapper .exe is a $host (not $build) application, just like the
"real" .exe. This means that libtool must be smart enough to convert new
$PATH settings from $build format to $host format, when writing the
source code for the wrapper exe. It also must convert the
path/to/real/exe from $build format to $host format, so that exec("")
has "the right stuff" for $host's exec() implementation -- or, in the
case of $host=mingw, _spawn().  In short, libtool has to manually
perform all the grunt work that used to be handled (or, with gcc's
current libtool, is now handled) by exec("$SHELL wrapper.script") via
the magic of the $SHELL and its posix runtime library (cygwin, msys) on
$build.

And that's the problem. I have a hunch that *right now*, if we dropped
in git-master-ToT libtool into gcc, your configure incantation would
fall over dead, because every executable's wrapper script (if built
using libtool) would have the "wrong" format of path/to/real/exe inside
_spawn("...") -- unless we dodged the bullet, as described above.

But even if we dodged the bullet for gcc, other packages which use
--build=mingw32 --host=mingw32 when $build is actually cygwin will NOT
be so lucky. So, *something* has to be fixed...

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/