Aaron W. LaFramboise wrote:
> My only input to this is that any resolution needs to be respectful of
> the fact that non-MSYS tools can be used with MinGW. In particular,
> Cygwin tools and ad-hoc Unix-like tool collections (such as unxutils and
> GnuWin32) should be supported as first-order MinGW configuration.
> Anything that assumes that MSYS is the only tool configuration for MinGW
> is incorrect, and the package structure needs to be set up to
> communicate this effectively.
> Unfortunately there are goofy and completely wrong things like the
> following that crop up if we don't keep this distinction clear. This
> particular instance I still need to look into and have corrected.
> From a recent libtool:
>> *mingw* )
>> case $build in
>> *mingw* ) # actually, msys
>> # awkward: cmd appends spaces to result
>> lt_sed_strip_trailing_spaces="s/[ ]*\$//"
>> func_to_host_path_tmp1=`( cmd //c echo "$1" |\
> It's wrong to assume the system is MSYS,
No, it is not wrong. If you tell configure (and thus, libtool) that
--build=mingw32, what is it supposed to think? Obviously you're not
running on "naked" windows, because libtool itself is a shell script,
not a .bat file. So SOME assumptions are in order. But this: "I should
guess that some unspecified collection of unix utilities may or may not
be available, and they may or may not accept dos-style and/or unix-style
paths with some automatic or manual translation mechanism. But
regardless of what IS or IS NOT available, I should always figure it
out, and do the right thing, with no surprises ever."
No, thanks. I'm just not smart enough to write and maintain that code
in a shell script.
> and it is wrong to call
> cmd--mostly, because this doesn't actually work on both old model and
> late model systems.
Sorry. Libtool never did specifically support w9x, and it's not about to
start now, seven years after microsoft EOLed it.
Anyway, these complaints are all libtool things, and not specifically a
mingw things (I should know; I wrote that bit). And it has nothing to
do with the naming convention mingw will use to package upstream
products, so I've changed the title of this subthread.
If there's a problem in the code for those upstream products like
libtool, the correct place to report bugs is bug-libtool@..., and
patches are always appreciated (if not quickly reviewed. Sigh.) at
The code you are looking at is still a work in progress. It's been
stalled now for almost six months, as I have had patches pending on the
libtool-patches list waiting review. The current cygwin release has the
Here's my thinking, for libtool, going forward:
1) "native" mingw ($host=mingw, $build=mingw) == mingw.org's MinGW
compiler on msys (and in that case, cmd IS available. See above WRT
win9x. I could see a well-tested patch to use $COMSPEC instead of
hardcoding cmd.exe, perhaps.)
2) mingw on cygwin: a true cross compiler. That is, a cygwin-hosted
mingw compiler, either supplied by the cygwin project or built on cygwin
using mingw.org's xscript. You'd configure the thing you're trying to
build using --build=cygwin --host=mingw. Note that this scenario is
***NOT*** mingw.org's native gcc accessed from cygwin. For that...
3) "Lie To Me". Running on cygwin, but using the mingw.org gcc. You'd
configure using --build=mingw --host=mingw (that's the "lie", because
--build is really cygwin) --- BUT, specifically related to the code
fragment above, you'd set a libtool cache variable before running
configure so it would DTRT, and not the (cmd ...) thing libtool would
normally do on "native" (that is, mingw/msys) builds.
Normally, for "native" [mingw/msys] builds, that variable is
autodetected to be func_msys_to_mingw_path_convert. this is obviously
not right when build is actually cygwin. AND, normally you'd simply be
told "don't lie to your tools". But, because this particular lie
currently works fairly well for a lot of people, I want to ensure that
it continues to work in the future.
4) wine. a linux-hosted mingw cross compiler. Works like a normal cross
compiler, but detects WINE and DTRT so that uninstalled executables --
including test programs -- can be run from WINE via the linux binfmt
I have most of this working fairly well now, if not extensively tested yet.
My primary goals with my ongoing libtool mods have been:
1) get libtool on mingw/msys working properly again, without the need
2) get wine-hosted mingw and cygwin target cross compiles working in
lt-2.2 at least as well, and hopefully better than, they did in lt-1.5
3) *DO NOT BREAK* the gcc developer-favored approach for windows-hosted
development: Danny Smith and Aaron both seem to use mingw (native) gcc
from within cygwin. This MUST continue to work properly -- although it
may require an extra environment setting or two. I figure those guys
aren't babes in the woods; they can handle it.
Now, as far a using gnuwin32 tools or unxutils to "host" libtool?
Sorry, I don't have NEAR enough cycles to make that work out of the box.
I won't go out of my way to break it, but most Gnuwin32 "installations"
are too haphazard about what is or is not present to make any kind of
functionality assumptions. If it works for you, great. Otherwise...you
can keep all the pieces.