Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson <cygwin@cwilson.fastmail.fm>]

Charles Wilson wrote:
[describe "old" libtool behavior; what I called "current gcc libtool"]
>  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

[contrast new libtool-git-ToT behavior]
> 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.

Wierd. It's been a while since I updated my local svn tree of gcc. It
finally finished, and I see that, in fact, current gcc trunk includes a
much newer version of libtool than I thought (2008-09-26==2.2.6ish, not
2007-03-18). So, in reality, *current* gcc libtool has the "new" behavior.

If that's working for you, Danny, then I guess gcc really did "dodge the
bullet" -- maybe libtool is never used in linking applications or test
progs within the gcc tree, so it's a moot point /for gcc/?

But, all the worries I listed still apply for *other* packages that
someone might want to compile using --build=mingw --host=mingw, when
$build is actually cygwin.  But it'd be wonderful to avoid all that
worry for the src/ tree!

--
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/