This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Cygwin 1.7 release (was Re: ??? The library or libraries will be delivered[...])
Corinna Vinschen wrote:
> On Jun 3 16:39, Charles Wilson wrote:
>> "backwards incompatible" [*] changes
I hope it was clear that I wasn't being critical of the fact that there
were some major changes in cygwin-1.7. I was just trying to halt the
"feature creep", since you (Corinna) have said that you plan to release
cygwin-1.7 in the next 3-4 weeks, if my math is right. There's barely
enough time left for one 1-month stabilization period, much less two or
three. And, we've just had a disruptive change that's gonna need our
remaining time-till-release to stabilize. So...let's not add another
major change. Modifying the BS sequence used by the cygwin terminal is
one thing...rewriting the console handling code entirely to exactly
follow exemplar X (be in Ubuntu's Linux Console, Red Hat's Linux
Console, xterm, or whathaveyou) is altogether another thing. Given THIS
list, we'd barely be able to decide WHICH exemplar to follow in one
month (then, because they are moving targets, we'd get to argue about
which epoch's behavior of Red Hat Linux we should match...) THEN, we
could get down to the brass tacks of making those changes, and testing
them. We don't have time between now and $RELEASEDATE to do any of that.
That's all I'm saying.
>> 1) dropping support for Win9x
>
> Uh oh.
>
>> 2) no longer launch native programs from long or virtual CWDs (before,
>> IIRC cygwin-1.5 would 'fake' the CWD as c:/ or something)
>
> This was always a bit weird. A 'cd /proc' never actually cd'ed to
> something, so a native Win32 process ended up in the previous cwd.
> We discussed this on cygwin-developers.
Ack. Again, I'm not *complaining*, just listing.
> As for long pathnames, they weren't accessible before at all.
>
> <rant>
> And it's really not my fault
Never said it was. I'm sorry I seem to have hit a nerve. That was
certainly not my intent.
>> 3) wide char support (and various existing changes related to LANG
>> settings in console and other terminal sessions)
>
> This turns out to be sort of a nightmare, but I'm still glad I did it.
Me too. It's just that it's a user-visible behavior change that we (for
various values of "we") are still trying to tweak just right. Let's not
add too many more of those, or we'll never make $RELEASEDATE.
> We now have full wide char support and setting $LANG/etc does really
> something useful. I can't imagine how painful it would have been to
> drag this change along in small steps.
Ack.
>> 4) removal of registry usage / new mount table
>
> That change only affects how mount points are stored. The day to day
> usage is the same, basically.
...except that didn't you (or cgf, or whoever) remove the 'copy over my
old registry-based mount points to /etc/fstab' code? If so, that's
gonna complicate the 'upgrade path' when we DO release. Not a *big*
deal, just one more surprising thing for our users who haven't been
paying attention to the mailing list. ("Snnnrrrk, what? Huh? I'm awake,
I'm awake...hey, what's this /etc/fstab thingy?")
>> 6) [possible] switch to gcc4 as official compiler (with associated
>> deliberate ABI breakage *without* DLL version number bumps -- see
>> http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html). It's pretty
>> clear this will happen *eventually*. Whether it happens
>> before/on/soon-after the 1.7 rollout is still TBD.
>
> That's still a sore point. Dave, is there any chance we can switch
> to gcc-4 as standard compiler for Cygwin 1.7 within the next 4 weeks?
Well, I wasn't trying to PUSH, mind you. There have been delays with
the whole gcc4 thing, but I've been paying some attention to Dave's
ongoing tribulations via the binutils and gcc lists, so I know *why*
there have been delays...
>> Each time we say "1.7 is a good time to..." and pull the trigger, it's
>> another month of stabilization. During that month somebody ELSE has a
>> bright idea about yet another thing "1.7 would be a good time to...".
>> This is not good.
>
> Yeah, we should stop right here. The biggest problem left is the
> native language support, apparently. I'm still hoping to get
> 1.7.1 out of the door end of this month, though.
Good news!
> What's left, AFAICS is
>
> - The usual bugfixing.
>
> - Creating the final version of setup-1.7.exe and replace
> cygwin.com/setup.exe with it.
>
> - Move the old documentation somehwere else, move the new docs to
> the old place. (And don't forget to remove the "1.7" subdir from
> the URLs in the docs).
>
> - Splitting off the union FS for release-2.
>
> - New versions of GCC and binutils would be nice. I'd especially
> appreciate if GCC would start to create executables with the TS-aware
> flag by default so that the distro is sort of self-healing in terms of
> running on Terminal Servers.
On that note...I've noticed some odd behaviors wrt the dynbase setting
under Vista. Sometimes Vista will fail to honor that flag, and I'll
still get the dreaded "*** unable to remap" message. While occasionally
a reboot will fix it, sometimes not. What's odd, tho, is that
sometimes I can "fix" it by re-running peflagsall and *removing* the
dynbase flag (AND rebooting). Then, adding it back (by re-re-running
peflagsall, and rebooting again) doesn't cause it to break again (at
least, not immediately). It'll be a week or more before the problem
shows up again. I haven't spotted any consistent rhyme or reason.
It's almost as if Vista just needs a kick in the pants by changing the
last-modified time of all the DLLs. It's all very strange.
But...I find myself planning ahead to ALWAYS maintain a cygwin-1.5
installation for the sole purpose of being able to run the test suites
of autoconf, automake, and libtool, with their TONS of autotool
invocations (because running the autotools, esp. automake, is where I
most often see the "unable to remap" problem). It takes DAYS of
constant attendence to run those tests when every five or six tests the
suite halts due to "unable to remap", during those times when Vista
decides to start ignoring dynbase. (Sure, I'll always need to
eventually run the suite(s) under 1.7, but since I sometimes run the
test suite a dozen times while iterating bugfixes -- esp. libtool --
I'll do most of that on 1.5 and then only last endure the 1.7 pain).
Now, this isn't to blame any of the work that's gone on in cygwin-1.7;
the fault here seems to lie with Vista. It's just odd that cygwin-1.7
seems so much more likely to tickle the fault. I'm hoping W7 improves
the implementation of ASLR (e.g. unlike Vista's "sometimes I feel like
ignoring the dynbase flag" behavior.) But if anyone wants to continue
THIS off-off-topic subthread, pls start YA new thread...I don't believe
this issue is a release-blocker, or even worth expending any effort on
at all between now and the release.
> Am I missing something else?
It'd be nice if the existing maintainers (if still around) of the
following packages:
expect
popt
binutils
units
byacc
psutils
par
xinetd
tcltk
could be persuaded to release updated versions that stop using /usr/man,
/usr/info, and /usr/doc in favor of /usr/share/man, /usr/share/info, and
/usr/share/doc. There may be other naughty packages, but those are the
ones I see on my system. But this change is not strictly *necessary*,
after all.
--
Chuck