Re: Some notes on building gcc-4.3.0
Brian Dessent wrote: Does this mean that we'll start to libgcc_s.dll's sprouting like mushrooms in the install dirs of various apps, or in *gasp* %WINDIR%/system32 over the coming years? Is this library versioned at all? What about conflicts? You already see the effects of this in the Linux world, with the more recent distributions having to ship a set of compat_libgcc_blah packages for each major (ABI-incompatible) previous release going back (they're on 4.1/4.2 these days, and there's one for 3.3 and one for 2.9). And most commercial/non-free software shipped on Linux (e.g. Oracle, Java, ..) just states explicitly which packages they depend on. So if I may offer a blueprint going forwards: * introduce a libgcc_something package containing the latest DLLs/.so's, and include it in the Base package. * later, if these are ever incompatibly ABI-rev'ed, switch the default distribution to the new version, and introduce a compat-libgcc-* package for the old version (which preserves their filename), and include that in the Libs package. -- 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/
Re: Some notes on building gcc-4.3.0
Shankar Unni wrote: You already see the effects of this in the Linux world, with the more recent distributions having to ship a set of compat_libgcc_blah packages for each major (ABI-incompatible) previous release going back (they're on 4.1/4.2 these days, and there's one for 3.3 and one for 2.9). It's just like any other library that is used by a lot of programs and has had a history of ABI changes. And most commercial/non-free software shipped on Linux (e.g. Oracle, Java, ..) just states explicitly which packages they depend on. Well of course, any functioning package management system requires this. So if I may offer a blueprint going forwards: * introduce a libgcc_something package containing the latest DLLs/.so's, and include it in the Base package. * later, if these are ever incompatibly ABI-rev'ed, switch the default distribution to the new version, and introduce a compat-libgcc-* package for the old version (which preserves their filename), and include that in the Libs package. I have no doubt that we won't encounter any problems getting this right on the Cygwin packaging end. That wasn't my concern. What worries me is that there is no packaging system at all for other users of gcc on Win32. If you want to distribute your MinGW compiled binary most of the time you just make a zip file of the required parts, including any DLLs, or maybe you use NSIS, MSI, whatever installer system of choice. The problem comes when one of these packages does a jerky thing like install a libgcc_s into the system32 dir. The regular user of Cygwin will be affected by these jerky installers if they put the file in system32 or if they put the file in their own install dir and add that install dir to the PATH. Now, I think we are mostly saved by the fact that traditionally Cygwin and MinGW libraries have always been distinguished by the cyg vs lib naming prefix, so if we continue with that for libgcc we will be mostly immune to idiot installers. But that doesn't do anything to help the MinGW guys, who I guess will have to rely on just having some form of version number as part of the DLL file name so that at least an ancient libgcc never overwrites a newer one because somebody installed DancingPonyScreenSaver v1.2 written by a clueless moron that drops its junk in \system32. But at the moment, neither of those two things (versioning and lib-prefix name) is handled by the gcc build system, so right now it's like driving in a car with no seatbelts and razor blades in the dashboard. Brian -- 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/
Re: Some notes on building gcc-4.3.0
Brian Dessent wrote:
Charles Wilson wrote:
C++ exceptions across DLL boundaries [*]
This also affects java. It is /NOT/ solved in 4.2, nor svn trunk. The
Official Way Forward is to get shared runtimes working...which explains
my patch-in-progress, above.
For the MinGW community for sure, and for the Cygwin community to a much
lesser extent, I can guarantee there are going to be people upset by
having to distribute these shared target libs
{cyg,lib}{gcc_s,stdc++}.dll with their app.
I predict they will turn to using the -static-libgcc option, which it
seems will cause broken exception handling in these cross-.so
circumstances. Not that this is any different on Linux, where apps that
want to throw/catch cross-.so will break with -static-libgcc, but at
least there it is custom and typical to have the shared target libraries
installed as part of the distro. Windows users seem infatuated with
this everything comes in the installer mentality.
Well, 80% of compiled code out there is plain old C, so -static-libgcc
won't hurt that at all. If somebody wants to ship a C++ or Java binary,
then they will have two choices: (1) ship with the DLLs (2) use
-static-libgcc and don't throw exceptions. Ever. Especially when using STL.
Are we really going to tell them that there is no choice in the matter,
that if they want cross-.so EH they must suffer shared libraries?
Yes. Microsoft does the same thing. They just have an inside advantage
in supplying their runtime with the OS.
They
will probably complain that they could get what they wanted from gcc 3.4
and will likely continue to use that version.
Ok. That doesn't worry me.
Does this mean that we'll start to libgcc_s.dll's sprouting like
mushrooms in the install dirs of various apps, or in *gasp*
%WINDIR%/system32 over the coming years?
Sadly, probably so. And it's worse than you know: because libgcc is not
built using libtool, it doesn't benefit from libtool's knowledge that
DLLs on cygwin should be called cyg*.dll. Thus, unless changes are
made, both mingw and cygwin will ship libgcc_s.dll files that users
will want to put in their $PATH -- only one relies on cygwin1.dll and
the other on msvcrt.dll.
Then, there's talk on the mingw list (and also here...) about dwarf2 vs.
sjlj. All of these dlls will be incompatible with each other. But
these are *platform* and *configuration* incompatibilities, not
*version* incompatibilities.
Is this library versioned at
all?
Sort of -- on ELF systems. In our case, no. However, *for a given
platform/configuration* the API is well-managed, in that only new
functions are ever added; old ones are never removed or changed (merely
obsoleted). So that's not really a problem.
What about conflicts?
See above. Don't despair; it's not as dire as it sounds. The trunk
*currently* doesn't build libgcc_s.dll with the special cyg* prefix --
because nobody has built it shared at all on win32, so the problem of
conflicting with mingw hasn't come up. Teaching the build system about
the cyg prefix is actually a fairly simple change.
The other is part policy, part implementation: suppose cygwin (or mingw)
ships both a dwarf2 and a sjlj compiler. Each one will provide runtime
dlls (libgcc_s, but also the libtool-built runtimes libstdc++,
libsupc++, libgfortran, etc etc). Under normal circumstances, you'd use
a different build/host/target:
configure target=i686-pc-cygwin-dw2 build=...dw2 host=...dw2
so they'd each get installed in separate directories. However the dlls
need to go into the main /bin/ so users can have a simple PATH -- so the
DLLs need different names.
That is, the dll names need to be sensitive to the target= specifier --
even tho the static libs and import libs should maintain their
standard names (otherwise we have to muck with the spec files and make
a lot of other intrusive changes).
So, you might have:
cyggcc_s_dw.dll i686-pc-cygwin-dw2/4.3.0/libgcc_s.dll.a
cyggcc_s.dll (sjlj) i686-pc-cygwin/4.3.0/libgcc_s.dll.a
cygstdc++-6_dw.dll i686-pc-cygwin-dw2/4.3.0/libstdc++.dll.a
cygstdc++-6.dll i686-pc-cygwin/4.3.0/libstdc++.dll.a
etc. In the libgcc case, we have to play games in libgcc/config/. In
the latter case...we need a new libtool/automake feature, I think.
Sometimes it seems like when you kill one weed, five pop up to take its
place.
Yep.
--
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/
Re: Some notes on building gcc-4.3.0
Charles Wilson wrote: Are we really going to tell them that there is no choice in the matter, that if they want cross-.so EH they must suffer shared libraries? Yes. Microsoft does the same thing. They just have an inside advantage in supplying their runtime with the OS. They will probably complain that they could get what they wanted from gcc 3.4 and will likely continue to use that version. Ok. That doesn't worry me. Well, after all, WJM. Sadly, probably so. And it's worse than you know: because libgcc is not built using libtool, it doesn't benefit from libtool's knowledge that DLLs on cygwin should be called cyg*.dll. Thus, unless changes are made, both mingw and cygwin will ship libgcc_s.dll files that users will want to put in their $PATH -- only one relies on cygwin1.dll and the other on msvcrt.dll. Yucko. See above. Don't despair; it's not as dire as it sounds. The trunk *currently* doesn't build libgcc_s.dll with the special cyg* prefix -- because nobody has built it shared at all on win32, so the problem of conflicting with mingw hasn't come up. Teaching the build system about the cyg prefix is actually a fairly simple change. The other is part policy, part implementation: suppose cygwin (or mingw) ships both a dwarf2 and a sjlj compiler. Each one will provide runtime dlls (libgcc_s, but also the libtool-built runtimes libstdc++, libsupc++, libgfortran, etc etc). Under normal circumstances, you'd use a different build/host/target: configure target=i686-pc-cygwin-dw2 build=...dw2 host=...dw2 so they'd each get installed in separate directories. However the dlls need to go into the main /bin/ so users can have a simple PATH -- so the DLLs need different names. That is, the dll names need to be sensitive to the target= specifier -- even tho the static libs and import libs should maintain their standard names (otherwise we have to muck with the spec files and make a lot of other intrusive changes). So, you might have: cyggcc_s_dw.dll i686-pc-cygwin-dw2/4.3.0/libgcc_s.dll.a cyggcc_s.dll (sjlj) i686-pc-cygwin/4.3.0/libgcc_s.dll.a cygstdc++-6_dw.dll i686-pc-cygwin-dw2/4.3.0/libstdc++.dll.a cygstdc++-6.dll i686-pc-cygwin/4.3.0/libstdc++.dll.a etc. In the libgcc case, we have to play games in libgcc/config/. In the latter case...we need a new libtool/automake feature, I think. I had noticed that Danny has been using --target=mingw32dw2 for his Dwarf2 builds so that they could be installed in parallel to the standard ones, so yes this sounds very sensible. Brian -- 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/
Re: Some notes on building gcc-4.3.0
Charles Wilson wrote: So, I thought I'd post my experiences, which ultimately resulted in a fully bootstrapped native cygwin compiler, with c,c++,objc,fortran,java frontends. Many thanks for this, Charles. At this point, why not to post also the resulting binaries so that Cygwin people can use them for tests? Perhaps this would help in developping GCC 4.3 under Cygwin. Cheers, Angelo. -- 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/
Re: Some notes on building gcc-4.3.0
Charles Wilson wrote:
C++ exceptions across DLL boundaries [*]
This also affects java. It is /NOT/ solved in 4.2, nor svn trunk. The
Official Way Forward is to get shared runtimes working...which explains
my patch-in-progress, above.
For the MinGW community for sure, and for the Cygwin community to a much
lesser extent, I can guarantee there are going to be people upset by
having to distribute these shared target libs
{cyg,lib}{gcc_s,stdc++}.dll with their app.
I predict they will turn to using the -static-libgcc option, which it
seems will cause broken exception handling in these cross-.so
circumstances. Not that this is any different on Linux, where apps that
want to throw/catch cross-.so will break with -static-libgcc, but at
least there it is custom and typical to have the shared target libraries
installed as part of the distro. Windows users seem infatuated with
this everything comes in the installer mentality.
Are we really going to tell them that there is no choice in the matter,
that if they want cross-.so EH they must suffer shared libraries? They
will probably complain that they could get what they wanted from gcc 3.4
and will likely continue to use that version.
Does this mean that we'll start to libgcc_s.dll's sprouting like
mushrooms in the install dirs of various apps, or in *gasp*
%WINDIR%/system32 over the coming years? Is this library versioned at
all? What about conflicts?
Sometimes it seems like when you kill one weed, five pop up to take its
place.
Brian
--
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/
Re: Some notes on building gcc-4.3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: I was testing Danny Smith's latest DWARF-2 patch, and building gcc from the current (rather unsettled) trunk was a bit tricky. So, I thought I'd post my experiences, which ultimately resulted in a fully bootstrapped native cygwin compiler, with c,c++,objc,fortran,java frontends. Thanks for the update; I was going to ask about the progress on this. First, I had to massage the tree in the following ways (and I was using revision 125636): Out of curiosity, have you done this with cygport yet? This made it all the way thru the three-stage bootstrap, and built most of the libraries. However, the build failed in libjava, due to stack overflow in jc1.exe. After manually relinking cc1.exe and jc1.exe with 100MB of stack (-Wl,--stack,10240) as recommended here: http://gcc.gnu.org/ml/gcc/2007-06/msg00151.html Interesting. I wonder if this would help with linking libsmokekde and libkdejava, both of which fail during linking for the same reason. Perhaps the other compilers should also be built with this flag for the same reason (and binutils' ld as well)? - From your notes, I gather that all libs are being built shared. If so, that's very good news, and I look forward to seeing this become readily available. To that end, a few questions: 1) What progress is being made to get these patches included upstream? 2) How long before gcc-4.3 will be stabilized enough to be generally usable? 3) Could you and/or others working on this keep this list updated on further progress? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcsH0piWmPGlmQSMRCNgJAJ9iSQYuES950VqWQeeJuFrsOwCfQn8S 6a+fDRJH1I6uCcx+EoWaa9I= =Uz0v -END PGP SIGNATURE- -- 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/
Re: Some notes on building gcc-4.3.0
Yaakov (Cygwin Ports) wrote: First, I had to massage the tree in the following ways (and I was using revision 125636): Out of curiosity, have you done this with cygport yet? No: it would impose too heavy a burden on my already overloaded plate. I'm using an alternate prefix (/opt) because I don't want to clobber my working gcc -- but cygport doesn't support prefixes other than /usr. I could patch cygport to add that functionality, but I've learned my lesson there. (furthermore, given the ~700MB svn directory, I'm thinking cygport's focus on unpack this tarball -- or, in this context, just-this-once-download-the-repo-then-make-a-tarball-but-strip-the-.svn-dirs, thus ensuring that you can never 'svn update' and that just-this-once is really over and over again -- would not win me any friends at gcc.org) That model works okay with less active projects (where you don't need to sync as much) or much much smaller projects (like libtool). But it's not a good fit for gcc. The difference between gcc and your massive KDE and/or gnome releases, is that you can pretty much treat each individual library or subproject separately. Gcc is basically a build-it-all-at-once kind of thing. That's ok. cygport -- or at least, my local version of -- solves many, even most, of the issues I've seen with maintaining/porting/compiling software on cygwin. It never will solve them all -- but it isn't the only tool in the toolbox, and that's fine. Interesting. I wonder if this would help with linking libsmokekde and libkdejava, both of which fail during linking for the same reason. Perhaps the other compilers should also be built with this flag for the same reason (and binutils' ld as well)? Well, 100MB is _really_ a lot of stack space. That was just the number that Dave Korn threw out on the gcc list. It was big enough -- but maybe 20M would be, also; nobody has done that analysis. And for multithreaded apps, you're talking 100MB /for each thread/. Fortunately, cc1 and jc1 are NOT multithreaded -- so you could probably get away with it (unless you want to compile libjava natively on your WinCE handheld...) However, I wonder if the real issue is just that somebody stupidified dbxout.c so that it is recursing a lot more than it should, or is allocating really big stuff on the stack. '-Wl,stack 100MB' smells like a workaround to me, and not a very good one. - From your notes, I gather that all libs are being built shared. If so, that's very good news, and I look forward to seeing this become readily available. Nope, no such luck: ... --with-arch=i486 \ --with-tune=i686 \ --disable-werror \ --disable-shared I've got a patch in the works that (a) successfully builds libgcc and libstdc++ shared (b) but any test app built using those dlls dies horribly. So, there's some work left to do (Danny himself uses an out-of-tree procedure, taking the existing .a's and turning them into .dlls. I have NEVER gotten that to work properly; perhaps I'm buying my sacrificial chickens from the wrong vendor) To that end, a few questions: 1) What progress is being made to get these patches included upstream? Well, Danny's dwarf2 stuff just went in this week. The other stuff -- I'm not sure: none of it is mine, and some of them are workarounds (e.g. the libstdc++ pr24196 thing would be better solved by getting shared runtimes, OR one could simply configure with --enable-fully-dynamic-string instead. So, it's unlikely that patch would be accepted, since it disimproves behavior for all other (sane) platforms. Worse, gcc is going into code freeze -- with the exception of merges from a few major project branches -- for a few weeks, starting today or tomorrow. This is specifically to stabilize the tree in light of those major project merges. Once that's done, then Mark is going to close stage 1... I'm not sure if the enable build shared on cygwin/mingw is stage-2 material. It's certainly not ready _now_ -- so if it isn't stage-2, then it must wait 'til 4.4. 2) How long before gcc-4.3 will be stabilized enough to be generally usable? Your guess is as good as mine -- as I said, Mark is closing stage-1 Real Soon Now; and stage-1 has been over eight months long (instead of the planned two) so that's good news for stability-in-the-near-future on most platforms. However, since getting performance and features equivalent to or better than the existing cygwin-gcc-3.4.x-special and mingw-gcc-3.4.x-special releases will require additional work, I don't know if that additional work will (a) get done in time for the eventual 4.3 release, or (b) be accepted into the tree during stage-2 or stage-3 development. While the testsuite converage on cygwin looks pretty good (given that only static runtimes are built), IMO there is one big -- huge -- regression in 4.2/4.3 with regards to the currently-shipping cygwin-gcc and mingw-gcc: C++
Some notes on building gcc-4.3.0
I was testing Danny Smith's latest DWARF-2 patch, and building gcc from
the current (rather unsettled) trunk was a bit tricky. So, I thought
I'd post my experiences, which ultimately resulted in a fully
bootstrapped native cygwin compiler, with c,c++,objc,fortran,java frontends.
Now, whether it actually *works* after installation -- dunno. Probably,
and bootstrapping is pretty good evidence, and building the target
runtime libs is even better, so...
OTOH, no warranty, express or implied, WJFFM, YMMV, etc etc...
First, I had to massage the tree in the following ways (and I was using
revision 125636):
1. patched /usr/include/stdio.h
See: http://www.cygwin.com/ml/newlib/2007/msg00296.html
the patch I used is attached.
2. patched classpath/native/fdlibm/mprec.h (_EXFUN issue)
See: http://gcc.gnu.org/ml/gcc/2007-04/msg00648.html
also attached
3. patched basic_string.[h|tcc] per pr24196
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
ditto.
4. danny's latest dwarf2 patch
See: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg02051.html
the gcc mailing list inlined the patch, so it needed lots of hand
fixups. I've attached another copy here.
5. extra dwarf2 patch for cygwin.h
It's in changelog of #4, but missing from patch...
6. fix for _GC_get_thread_stack_base issue
See http://gcc.gnu.org/ml/gcc/2007-03/msg00790.html
I configured as:
$ ../gcc/configure \
--prefix=${PREFIX} \
--exec-prefix=${PREFIX} \
--sysconfdir=${PREFIX}/etc \
--libdir=${PREFIX}/lib \
--libexecdir=${PREFIX}/lib \
--with-datarootdir=${PREFIX}/share \
--enable-languages=c,c++,objc,fortran,java \
--with-gcc \
--enable-nls \
--without-included-gettext \
--enable-version-specific-runtime-libs \
--without-x \
--enable-libgcj \
--disable-java-awt \
--with-system-zlib \
--enable-interpreter \
--disable-libgcj-debug \
--enable-threads=posix \
--enable-java-gc=boehm \
--disable-win32-registry \
--disable-sjlj-exceptions \
--enable-hash-synchronization \
--enable-libstdcxx-debug \
--enable-cxx-flags='-fno-function-sections -fno-data-sections' \
--disable-symvers \
--enable-libgomp \
--with-arch=i486 \
--with-tune=i686 \
--disable-werror \
--disable-shared
Where PREFIX=/opt (I had already built and installed binutils with the
same PREFIX).
$ make bootstrap 2err.log 1out.log
This made it all the way thru the three-stage bootstrap, and built most
of the libraries. However, the build failed in libjava, due to stack
overflow in jc1.exe. After manually relinking cc1.exe and jc1.exe with
100MB of stack (-Wl,--stack,10240) as recommended here:
http://gcc.gnu.org/ml/gcc/2007-06/msg00151.html
I kicked off the build again (see below). Check 'out.log' to get the
correct commandline to relink those two apps, and then just add
-Wl,--stack,10240
$ make all-target LDFLAGS=-LBUILDDIR/i686-pc-cygwin/libgcc \
2err2.log 1out2.log
NOTE: I added the absolute path to the libgcc target directory to
LDFLAGS because otherwise, when trying to link the applications, any
installed libgcc.a in the target ${PREFIX}/lib/gcc/${ARCH}/4.3.0/
directory will be used, instead of the newly built one. In my case, the
installed one was an older 4.3.0 version without the necessary DWARF2
unwind symbols, and ... boom.
NOTE2: I also had a weird but transient problem with missing symbols
related to the HTML_401F class in libjava. As it happened, I ran out of
virtual memory while trying to compile that class, so I ended up with a
HTML_401F.o that had NO symbols at all. After rebooting and shutting
down all unnecessary processes, I was able to get that file to compile
correctly. It required just over 1GB of memory to compile that ONE
file: on my 512MB machine with 1GB VM file, that was...painful.
--- stdio.h.orig2007-06-12 22:10:21.979328000 -0400
+++ stdio.h 2007-06-12 22:08:57.588703000 -0400
@@ -402,7 +402,38 @@
#define __sgetc_raw_r(__ptr, __f) (--(__f)-_r 0 ? __srget_r(__ptr,
__f) : (int)(*(__f)-_p++))
#ifdef __SCLE
-static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
+/* For a platform with CR/LF, additional logic is required by
+ __sgetc_r which would otherwise simply be a macro; therefore we
+ use an inlined function. The function is only meant to be inlined
+ in place as used and the function body should never be emitted.
+
+ There are two possible means to this end when compiling with GCC,
+ one when compiling with a standard C99 compiler, and for other
+ compilers we're just stuck. At the moment, this issue only
+ affects the Cygwin target, so we'll most likely be using GCC.
+
+ The traditional meaning of 'extern inline' for GCC is not
+ to emit the function body unless the address is explicitly
+ taken. However this behaviour is changing to match the C99
+ standard, which uses
Re: Some notes on building gcc-4.3.0
It'd be nice if the archiving software would Do What I Mean and Not What I Say. It inlined all the patches. So, here's a tarball... -- Chuck gcc-4.3.0-patches.tar.gz Description: GNU Zip compressed data -- 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/
Re: Some notes on building gcc-4.3.0
On Wed, 13 Jun 2007, Charles Wilson wrote: It'd be nice if the archiving software would Do What I Mean and Not What I Say. It inlined all the patches. So, here's a tarball... The patches did come through as text attachments, though... And you can get the whole message from the archives in mbox format via the Raw text link. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-'old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for nothing left to lose... -- Janis Joplin -- 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/
