Mail Archives: cygwin/2009/01/29/04:52:52
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/
- Raw text -