This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.x goes current on 2003-08-23?

Gerrit P. Haase wrote:
Hallo Nicholas,


Perl-5.8 is not working at all on WinME and, despite my best efforts, I
am unable to debug the problem because the "race" condition happens before the dubugger can hook. As Jason points out in the release notes, even after being rebased, Python cannot pass any of the threads or

^^^^^^ Python also cannot be built with Cygwin 1.5.1?

No, I *was* referring to Python-2.2.x, please see the release notes for what tests failed on which platform.

Why not upgrading to W2K or XP?
You can get W2K really cheap at second hand shops;)
Last time I was at I saw that they don't support
Internet Explorer 5 and 5.5 any longer. That means that the support
for Win98/ME will also be dropped soon as it already happens now for
Win95 (you cannot install IE6 on W95). I cannot believe that there
are some users out there who still work with their first, ten years
old, Pentium I, 90Mhz box which cannot run W2K because their 4 GB
harddisk is too small and they cannot upgrade the hardware because the
BIOS is too old to recognize some hardisk larger than 4 GB and are
really happy that they could install Win98 because it gives you the
look and feel of a real system. </flame>

Thank you for informing about something I'm already aware of, but I do not feel like upgrading to XP (yet). Frankly, I shouldn't have to! If anything, I'd rather *downgrade* to Windows98se. To me there are NT'isms which are just a big PITA. My notebook won't work with Win2000, so I'm forced to go to XP if I upgrade. Plus, I don't care *at all* for all that colorful shit in XP. It looks like that stuff is part of the new UI, so the prospects of getting rid of that crap looks slim. I could be wrong, because I haven't bothered to even investigate it. As for IE, well I could care less, since as you can tell from my X-Mailer, I use Netscape/Mozilla. Anyhow, the point of the matter is:

Perl is required for many operations, and (as I'm sure Chuck will agree) having to rebase a *critical* core application *just* to get it work is unacceptable. The question is: What has changed in perl to make it so problematic? No offense to Jason, but rebase is really just "papering" over a much bigger infrastructure problem which isn't going away. The problem is that "rebase all" only takes into account the dll's installed by the installer. It certainly doesn't take into account dll's which aren't named ".dll" (like in Ruby which leaves them named *.so). It also won't take into account user-installed dlls or perl modules. I've managed to work around this on my Win2k machine by modifying rebase all to use `locate` and to run rebase on any ".so"'s it finds in the Ruby dir. I don't have a solution, but I think it is something which needs to be kept in mind when talking about these "issues" which are starting to become more and more prevelant. Another thing to consider is: Why doesn't UWIN experience the same problem? IIRC, they use a system driver to interface with the windows kernel and to manage memory. Maybe the solution requires a more lowlevel approach (leveraging the interfaces provided by the ddk), rather then trying to use conventional means? It might even provide greater performance if could bypass some of the upper layers of windows API.

I know you don't care about the Windows ME users, but the fact of the matter is that the new perl makes Cygwin almost useless as a development tool on WinME since it breaks autoconf/libtool/automake to name a few. Soon it may be said that: Cygwin will not work on WinCE and WinME :-(.

If my remarks seem petulant, Good! Don't tell me to read the f*&king FAQ or to search the archives [which use that useless htdig engine]! And I'm sick and tired of hearing that cliche "Use the source, Luke", so don't even go there... Sorry if this offends anyone, but all's fair between the the "flame" delimiters...

Also, for 5.8.1, can you turn back on MakeMaker's bzipping of manpages, like you had during the 5.8.0RC's? You might also considier targeting /usr/share/man, as that is what we are hoping to transition to...

IIRC, I compressed the manpages manually, but if there is a feature in
perl that allows to do this automagically, I can turn it on.

I might be confused, but I swear you had flipped it on for 5.8.0-RC2. Maybe I'm thinking about my linux-from-scratch box...

I thought we allow /usr/man and /usr/share/man to coexist?

Why not transition now, now is as good a time as any...


$ ( cd /usr/man ; du -hs )
9.9M    .

$ ( cd /usr/man ; df -h . )
Filesystem            Size  Used Avail Use% Mounted on
H:                     60G   29G   31G  49% /

And: Hardisks are really cheap, 120GB -> $100.

And if that all doesn't help:
$ (cd /usr/man ; find . -name "*.3pm" | xargs bzip2 -9 )

At least for the perl modules manpages it is easy to maintain this

That's not the point, you assume that I have a desktop, which is not true in one case for me. Laptop hard drives were and still are prohibitively expensive and their controllers don't always allow for greater capacities. When making an application, would you use a long double when a char is all you need? Little things add up, and I think our goal should be to save space when possible without sacrificing performance. Reducing the size of the install base, even by 10-20mb is a good thing. Otherwise, why do we even bother stripping binaries?


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]