[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cygwin] cwrapper emits wrapper script
Re: [cygwin] cwrapper emits wrapper script
Wed, 25 Apr 2007 18:41:08 -0400
On Wed, 25 Apr 2007 23:01:10 +0200, "Ralf Wildenhues"
> FWIW, this isn't going to change a lot for me. If I have doubts that
> changes are free of regressions, then there is work to be done.
> not helpful if GCC developers have to sort out those regressions.
> Conversely, if GCC retains the policy of updating its Libtool files at
> most once every decade, then we can't help them, no matter what bug
> we're talking about.
Right. The problem was that they had modified their local version of
libtool-1.4.x, and were therefore nervous about upgrading and losing
those "fixes". Plus, they had to update autoconf from 2.13 and automake
from 1.[4p5|7|8,depending] throughout, first -- and that took a while.
A looonnnng while.
However, similar problems should be avoided in the future, because from
what I understand, the new rules are: either use an official, unpatched,
released version of external tools (like libtool), or use an unpatched
version taken directly from the external development tree. The only
problem I see is if libtool-HEAD-after-2.0 (say, nearing the /next/
major release) begins requiring ac-2.61/am-1.10 (or even newer). Then
gcc would be stuck with their unpatched snapshot of libtool-HEAD from
before that new libtool requirement, until they updated ac/am.
I suspect they will make more of an effort to keep up with current
autotools, plus I think any future ac/am updates will be much less, err,
issue-prone than the ac-2.13/ac-2.5x transition was.
> Primary aim is to release Libtool 2. Effectively you are suggesting
> that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW
> breakage of cwrapper be considered release blockers.
The latter two, yes: see below. The first one: no. Only, if you ARE
going to accept it before 2.0, then I'd prefer to get that done before
the upcoming gcc import, rather than miss it by a few days. If you're
NOT going to accept it pre-2.0, or if it takes a month to stabilize and
we miss the gcc "deadline" by _weeks_, then no problem.
> Which I personally don't have a problem with, especially if you're the
> one doing all the hard work and effectively end up doing the maintenance
> as well. ;-) But I think that should be noted. And the next time you
> cry about the release process being ever slower, I'll remind you of this
> point. ;-)
I call shenanigans. The argz stuff notwithstanding, the very idea of
fixing the "transparent_exe" issue &etc was rejected by me a year ago as
being too destabilizing for 2.0(.0), which was due Real Soon Then.
"Sadly, it's too late for any such major change to get into
libtool-2.0[ed: 2.0.0 initial release] because libtool is effectively in
code-slush right now. But, if *somebody* implements this fix I'll put it
in cygwin's dist of libtool-2.0 and push for it to go into
libtool-2.0.x.[ed: x > 0]"
It was rejected AGAIN by me two weeks ago as being too destabilizing for
"Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
It was you who said in response, last week:
"... I'd prefer to see such a patch before deciding when it's good to
put it in."
So, I began feeding those patches. I was surprised when you accepted in
principle -- and then actually committed -- the first "use functions to
emit wrapper code" patch without even seeing the others. Despite my
surprise, I continued feeding the others, because if one of the three
patches was actually accepted, code slush or no, then I really didn't
want the official libtool-2.0(.0) to have only a partly finished
implementation (only one of the three phases). Granted, I have
implemented all three phases with only backwards-dependence:
HEAD+phase1-only works. HEAD+phase1-and-phase2-only works.
HEAD+all-three-phases works. There's no functional breakage by taking
only phase1, or only phase1 and phase2. But it strikes me as odd to do
so, else why take phase 1 at all?
Note that my original email, from last year, actually specified three
separate phases, and strongly implied that they would each be
implemented separately (e.g. three separate patches) -- although my
implementation, and theory-of-operation, of #2 was a bit different than
I originally proposed, causing #3 to differ as well. But that's beside
The argz stuff: actually fixes a _bug_ that was exposed by failing mdemo
tests on cygwin, which began failing ~six months ago (I no longer
remember exactly when, nor what change in either libtool or cygwin was
the proximate cause; perhaps cygwin first began exporting the newlib
argz symbols?). The mingw change fixes a hitherto unnoticed bug in that
the mingw wrapper executables _did not work_ -- ever. I suspect the
upcoming MSYS-1.0.11 release with its updated coreutils and bash might
actually expose this bug, in that foo.exe will now be preferred over
foo, just like on cygwin. So, yeah, I think these two ARE release
The three-phase "go away pesky foo.exe/foo wrapper confusion" patches
are NOT release blockers. That's why I said (above) 'if possible and
[Ralf|Gary|others]' -- using whatever stringent standard you wish to
apply. You'd already accepted phase 1, so...if you had already decided
to accept phase 2 and phase 3 before releasing 2.0, then I wanted to do
it sooner rather than later, for outside (gcc) reasons.
However, if you wish to delay phase 2 and phase 3 until post-2.0, that's
fine too -- and I'll code up the mingw exe wrapper fix separately.
Re: [cygwin] cwrapper emits wrapper script, Charles Wilson, 2007/04/27