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/
