Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 15 02:48, Brian Dessent wrote: Corinna Vinschen wrote: They do? How and Why? Is that something which should be rather fixed in newlib instead of in the autogen configuration? The BSD implementation of funopen() doesn't explicitly define any types for the cookie functions, but simply says they should match the signatures of read(2), write(2), lseek(2), and close(2). Autogen tried to define the following if it detected that funopen() exists: typedef int (cookie_read_function_t )(void *, char *, int); typedef int (cookie_write_function_t)(void *, const char *, int); typedef fpos_t (cookie_seek_function_t )(void *, fpos_t, int); typedef int (cookie_close_function_t)(void *); However the newlib implementation explicitly defines these types as: typedef ssize_t cookie_read_function_t(void *__cookie, char *__buf, size_t __n); typedef ssize_t cookie_write_function_t(void *__cookie, const char *__buf, size_t __n); # ifdef __LARGE64_FILES typedef int cookie_seek_function_t(void *__cookie, _off64_t *__off, int __whence); # else typedef int cookie_seek_function_t(void *__cookie, off_t *__off, int __whence); # endif /* !__LARGE64_FILES */ typedef int cookie_close_function_t(void *__cookie); So you got an error because the types differ. I don't see anything wrong with the newlib definitions here, as they match the prototypes of read/write/etc. I'm not sure why autogen was trying to define them using int instead of size_t or ssize_t, but that's what it was doing and it was apparently succeeding because the BSD headers didn't have any typedefs. I see. So what we have in newlib is how it's defined on Linux. Howver, shouldn't autogen have the same problem on Linux then? If not, any idea why? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
First of all, I couldn't have said anything better than Brian did. On Apr 14 20:37, Brian Dessent wrote: For example I recently tracked down a configure issue in autogen where it assumed the BSD signatures of the types used with funopen(), which differ from the implementation in newlib. They do? How and Why? Is that something which should be rather fixed in newlib instead of in the autogen configuration? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
Corinna Vinschen wrote: I see. So what we have in newlib is how it's defined on Linux. Howver, shouldn't autogen have the same problem on Linux then? If not, any idea why? I suppose it's because on linux, HAVE_FOPENCOOKIE would be set and this code would be skipped. It was only when HAVE_FOPENCOOKIE was not defined but HAVE_FUNOPEN was that it tried to include the typedefs. The HAVE_FOPENCOOKIE codepath was unusable on Cygwin because it assumed presence of libio.h when fopencookie() is present, and while newlib has fopencookie() it has no such libio.h. I haven't looked at CVS autogen but Bruce said he was going to fix both of these issues so hopefully this is all resolved now. Brian
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 3:50 AM: | | I see. So what we have in newlib is how it's defined on Linux. fopencookie matches Linux. Linux does not have funopen. I guess the reason funopen disagrees with BSD is that BSD took a different path to 64-bit I/O than newlib years ago; I'm not sure that I broke things any worse than they already were when I worked on making funopen reliable (it was already declared before my patches). | Howver, shouldn't autogen have the same problem on Linux then? I guess the problem here is that autogen assumed a header that newlib doesn't provide - it would be relatively easy to add a stub libio.h to cygwin (or even newlib). Speaking of newlib stdio functions, shouldn't we go ahead and export fopen_memstream and fmemopen, as those will be required by POSIX 200x (and have a more standardized interface than either funopen or fopencookie)? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgEmjwACgkQ84KuGfSFAYAAGACgqVftklHTBGx9OkOlhaax9WwH GrMAoMjwdL67vt8ekVKNQI5XfC0g3ws3 =iijv -END PGP SIGNATURE-
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 15 06:06, Eric Blake wrote: Speaking of newlib stdio functions, shouldn't we go ahead and export fopen_memstream and fmemopen, as those will be required by POSIX 200x (and have a more standardized interface than either funopen or fopencookie)? IIRC, you implemented it. Did I miss a patch from you to cygwin-patches to enable them in Cygwin? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 6:15 AM: | On Apr 15 06:06, Eric Blake wrote: | Speaking of newlib stdio functions, shouldn't we go ahead and export | fopen_memstream and fmemopen, as those will be required by POSIX 200x (and | have a more standardized interface than either funopen or fopencookie)? | | IIRC, you implemented it. Did I miss a patch from you to cygwin-patches | to enable them in Cygwin? I thought I had, but looking in the archives, I don't see it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgEnuQACgkQ84KuGfSFAYA87gCfXztHIDKbczA5FKkbbDbUdpgs NUYAnirRCVlUcgGr0yX1z5SuftJtmszE =jj44 -END PGP SIGNATURE-
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Mon, Apr 14, 2008 at 8:11 AM, Corinna Vinschen [EMAIL PROTECTED] wrote: Hi all, we're now finally starting the release cycle for Cygwin 1.7. Not everything is in it's place, some changes are still in flux and the installation is still somewhat bumpy but we should get to all of that while testing goes on. We have set up a new release area which is dedicated to the 1.7 release. This allows us to test the new Cygwin DLL in a complete distro environment without breaking the standard release. This standard release will get frozen at one point, when we think it's safe enough to switch the community to the new distro. The old one stays available for Windows 95/98/Me users. So far the new release area is a copy of the existing one. To access it, you have to use a special setup.exe version you get from http://cygwin.com/setup-1.7.exe I was / am very happy to see this available. I frequently run in to the path / filename too long error. I downloaded this version of setup and when I run it (I have tested it against 5 or 6 different mirrors), it fails on 99% complete. The setup dialog shows that it is Downloading _update-info-dir-00743-1.tar.bz2. Is there anything I can do to get past this point? Thanks Troy
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen wrote: Hi all, we're now finally starting the release cycle for Cygwin 1.7. Not everything is in it's place, some changes are still in flux and the installation is still somewhat bumpy but we should get to all of that while testing goes on. We have set up a new release area which is dedicated to the 1.7 release. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. cgf
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 14 10:39, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen wrote: Hi all, we're now finally starting the release cycle for Cygwin 1.7. Not everything is in it's place, some changes are still in flux and the installation is still somewhat bumpy but we should get to all of that while testing goes on. We have set up a new release area which is dedicated to the 1.7 release. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. Oh, hmm, I assumed you would do that anyway at one point. I'm just a bit surprised that the resulting purged directory is still that big. I thought that more than half the size would be obsolete and prev packages. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Mon, Apr 14, 2008 at 05:27:58PM +0200, Corinna Vinschen wrote: On Apr 14 10:39, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 03:11:56PM +0200, Corinna Vinschen wrote: Hi all, we're now finally starting the release cycle for Cygwin 1.7. Not everything is in it's place, some changes are still in flux and the installation is still somewhat bumpy but we should get to all of that while testing goes on. We have set up a new release area which is dedicated to the 1.7 release. I was hoping to get a little more feedback on using the union fs before we announce this. I'd like to use the mechanism that I mentioned since it would be the most transparent for package maintainers. In keeping with the full-steam approach I guess I'll put it into place today. Oh, hmm, I assumed you would do that anyway at one point. It will be a pain in the neck to do it if people start updating the current cygwin-2 directory while I'm trying to perfect the unionfs version. I'm just a bit surprised that the resulting purged directory is still that big. Yes, well, er, there was a pretty serious bug in my purge script on the order of How could that have possibly done anything right? variety. Looks like I have to start from scratch and do the purge again. Sigh. cgf
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
On Apr 14 11:42, Christopher Faylor wrote: On Mon, Apr 14, 2008 at 05:27:58PM +0200, Corinna Vinschen wrote: Oh, hmm, I assumed you would do that anyway at one point. It will be a pain in the neck to do it if people start updating the current cygwin-2 directory while I'm trying to perfect the unionfs version. Ok, so let's not create new packages for the next couple of days. I will just update the Cygwin package itself if serious bugs crop up, that should be ok, right? Just for clarity, do you mean release-2 parallel to release, or cygwin-2 parallel to the parent cygwin dir? I'd expect the latter might actually break a lot of mirrors which explicitely mirror the cygwin directory only. release-2 seems less error prone on the mirror side. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
The most important changes on the user level are the long path name support including UTF-8 character support, as well as IPv6. Other changes are also important, but these two will likely have the most impact. I'd like to ask you to keep an eye especially on them when building and testing. OK, a few questions and comments: (1) Do all packages that include compiled code need to be rebuilt for Cygwin 1.7? IOW, is ABI compatibility broken from 1.5? Also, I presume that there would be no need to rebuild any packages that don't include compiled code, e.g. packages that depend only on Perl or Python. (2) If I understand right, the implication here seems to be that although Cygwin 1.7 will support the above features, it's going to be up to us package maintainers to ensure, or at least just test, that our packages support them too. But, there seems to be no requirement about that. That is, we could just dump our packages as they are into Cygwin 1.7, and not test them for any of the new supported features, assuming our consciences allow this. Correct? (3) For packages that have been tested, are we going to have a standard and/or common location or format in which to put our tested against Cygwin 1.7/tested for long file name/UTF-8/IPv6/etc. support results? Or just note the results or not in our README.Cygwin files? The latter seems fine to me, I'm just wondering. (4) It seems that it might be useful to develop standard unit tests for some of these features. Long file name support is simple enough-- we just have to create some path names longer than 260 characters, and try feeding them to our applications. But for UTF-8 and IPv6 support, it could take each of us a lot of time to work out tests on our own. Or at least, it would take me a while since I'm mostly ignorant of them... A standard, documented approach would sure help me, and maybe other packagers too. I freely admit though that I am not volunteering to do this. Thanks, Andrew.
Re: [HEADSUP] Start of Cygwin 1.7 release cycle
Andrew Schulman wrote: (1) Do all packages that include compiled code need to be rebuilt for Cygwin 1.7? IOW, is ABI compatibility broken from 1.5? Also, I presume that there would be no need to rebuild any packages that don't include compiled code, e.g. packages that depend only on Perl or Python. No, it should be fully ABI backwards compatible, it's just that recompilation will be required to enable the new features. For example if the app allocated its path buffers based on PATH_MAX (260 in 1.5, 4096 in 1.7), it will not be able to take advantage of long pathnames even if the DLL would support it. And likewise for ipv6 support, fopencookie, etc. Those features would not have been detected by the package's configure script and thus disabled in 1.5, but they would be detected and enabled when rebuilt against 1.7. And it's that fact (new codepaths exposed in the app) that needs testing. (2) If I understand right, the implication here seems to be that although Cygwin 1.7 will support the above features, it's going to be up to us package maintainers to ensure, or at least just test, that our packages support them too. But, there seems to be no requirement about that. That is, we could just dump our packages as they are into Cygwin 1.7, and not test them for any of the new supported features, assuming our consciences allow this. Correct? Well, part of the implication of the above is that some packages might not build against 1.7 without tweaks. For example I recently tracked down a configure issue in autogen where it assumed the BSD signatures of the types used with funopen(), which differ from the implementation in newlib. funopen/fopencookie didn't exist in 1.5 and are new in 1.7, so these issues would have never been exposed when building the package against 1.5, but the new feature exposed the codepath in autogen that tried to use funopen, which needed some tweaks to work with Cygwin. In my completely unofficial opinion I'd say that it's always at the maintainer's judgement how to deal with these things. In most cases if a feature does not work you can simply disable it by configuring with --disable-foo, or e.g. in the case of autogen by configuring with ac_cv_func_fopencookie=no ac_cv_func_funopen=no ./configure ... forced those features to be disabled since the configure tests were broken. But ideally it would be best if whatever compatibility problems arise can be dealt with so that the package builds as close to OOTB as possible, and so that the new functionality is enabled in the app. (3) For packages that have been tested, are we going to have a standard and/or common location or format in which to put our tested against Cygwin 1.7/tested for long file name/UTF-8/IPv6/etc. support results? Or just note the results or not in our README.Cygwin files? The latter seems fine to me, I'm just wondering. I can't speak for anyone else but the way I invisioned this working is: - maintainer uploads 1.7-built package to the 1.7 release area - other 1.7 testers install it in their 1.7 tree - problems are reported to this list - maintainers fix the issues, upload updated packages to the 1.7 release area - after sufficient iterations of this, the 1.7 area is declared ready for prime time, and is switched over to the default distro instead of being a sandboxed area Of course if you want to note in the README.Cygwin the changes/tweaks that were necessary for each package bump, that would probably help everyone. But the fact that the package exists in the 1.7 area at the time that it goes live would be the main indicator that it's passed somebody's definition of (at least minimal) working. In other words, if there's some really hairy unsolvable problem with a 1.7-built package, it should be removed from the 1.7 area and the old 1.5-built version used until the problem is fully resolved. (4) It seems that it might be useful to develop standard unit tests for some of these features. Long file name support is simple enough-- we just have to create some path names longer than 260 characters, and try feeding them to our applications. But for UTF-8 and IPv6 support, it could take each of us a lot of time to work out tests on our own. Or at least, it would take me a while since I'm mostly ignorant of them... A standard, documented approach would sure help me, and maybe other packagers too. I freely admit though that I am not volunteering to do this. Yes, I'm sure all of those things would be helpful. We don't have to be perfect either. We should be realistic in that the number of people that are clued enough to monitor this list and download a separate setup.exe and follow the steps to install an experimental distro is going to be much smaller than the general userbase of Cygwin, so we won't be able to suss out every problem before the 1.7 area goes live. I think that's fine, we just need to get things into a good enough state. Brian
