[HEADSUP] Start of Cygwin 1.7 release cycle

[HEADSUP] Start of Cygwin 1.7 release cycle

[Corinna Vinschen]

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

The idea is this:

- You set up a local Cygwin 1.7 installation.  

- You build the packages you maintain under that Cygwin 1.7 release.

- You prepare the packages for uploading into the 1.7 release area.

- You report bugs to the cygwin list (maybe we should set up a
  temporary cygwin-test mailing list for a couple of months?).

Over the time the Cygwin 1.7 release area will be populated with
corresponding packages.  The more packages we have, the easier
will get further testing, especially for the two most intrusive
changes, IPv6 support and long path names.

However, right now we have still a problem.

The new Cygwin DLL uses /etc/fstab and /etc/fstab.d/$USER files instead
of the registry for the mount table.  While this decouples the new
release from an old one in terms of mount points, setup.exe still
accesses and creates registry mount points and stumbles over that.

As a result, for now I'd suggest to install Cygwin 1.7 only if you
have a spare machine or in a distinct virtual machine.  Once setup
can deal with a parallel 1.5 release, this gets much easier.

Below you'll find a list of the major changes from 1.5 to 1.7.  Please
read it carefully.

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.

The most important changes on the application level are the new Cygwin
functions for path name conversion between DOS and POSIX filenames
which, in contrast to the previous functions, allow long path names.
The old functions are marked as obsolete in the header file, so you will
get approrpiate warnings if your application is using them.  The new
functions are already documented (including example code), though, for
the time being, only in the Cygwin sources (see
winsup/cygwin/path.sgml).

Please note that, besides other stuff, two really crucial changes are
still missing:

- Native Language Support and the character set handling according to
  $LANG and $LC_CTYPE is still lacking.  I'm glad to report that
  Kazuhiro Fujieda volunteered to work on that.  For now, you have to
  set CYGWIN="codepage:utf8" as well as LC_CTYPE="C-UTF-8" to get UTF-8
  support working.  This should get much simpler and better after
  Kazuhiro's patches.  

- Documentation (Heeeeelp!)

Ok, if something is unclear, feel free to ask.  Other than that, enjoy
the below list of changes and the new functionality.


Corinna


Wind^WList of Changes:
======================

OS releated changes:
--------------------

- Windows 95, 98 and Me are not supported anymore.  The new DLL will
  not run on any of these systems.

File Access related changes:
----------------------------

- Mount points are no longer stored in the registry.  Use /etc/fstab
  and /etc/fstab.d/$USER instead.  Mount points created with mount(1)
  are only local to the current session and disappear when the last
  Cygwin process in the session exits.

- PATH_MAX is now 4096.  Internally, path names can be as long as the
  underlying OS can handle (32K).
  
- UTF-8 filenames are supported now.  So far, this requires to set
  the environment variable CYGWIN to contain "codepage:utf8", but this
  will likely disappear in a few weeks time.  The setting of $LANG or
  $LC_CTYPE will be used instead.

- Creating filenames with special DOS characters '"', '*', ':', '<',
  '>', '|' is supported.

- Creating files with special DOS device filename components ("aux",
  "nul", "prn") is supported.

- Managed mounts are now identical to normal mounts, except they allow
  to create files only differing by case ("abc", "Abc", ABC").

- unlink(2) and rmdir(2) try very hard to remove files/directories even
  if they are currently accessed or locked.  This is done by utilizing
  the hidden recycle bin directories and marking the files for deletion.

- rename(2) rewritten to be more POSIX conformant.

- Add st_birthtim member to struct stat.

- File locking is now advisory, not mandatory anymore.  The fcntl(2) and
  the new lockf(2) APIs create and maintain locks with POSIX semantics,
  the flock(2) API creates and maintains locks with BSD semantics.
  POSIX and BSD locks are independent of each other.

- Implement atomic O_APPEND mode.

- Handle NTFS native symlinks available since Vista/2008 as symlinks.

- Recognize Netapp DataOnTap drives and fix inode number handling.

- Recognize Samba version beginning with Samba 3.0.28a using the new
  extended version information negotiated with the Samba developers.

- Support Linux-like extended attributes ([fl]getxattr, [fl]listxattr,
  [fl]setxattr, [fl]removexattr).

- New file conversion API for conversion from Win32 to POSIX path and
  vice versa (cygwin_conv_path, cygwin_create_path, cygwin_conv_path_list).

- Other new APIs: posix_fadvise, posix_fallocate, funopen, fopencookie,
  fdopendir.

Network related changes:
------------------------

- New implementation for blocking sockets and select on sockets which
  is supposed to allow POSIX-compatible sharing of sockets between
  threads and processes.

- Restrict send/sendto/sendmsg to send never more than 64K to circumvent
  internal buffer problem in WinSock.  (May need rework)

- IPv6 support.  New API getaddrinfo, getnameinfo, freeaddrinfo,
  gai_strerror, in6addr_any, in6addr_loopback.  On IPv6-less systems,
  replacement functions are available for IPv4.  On systems with IPv6
  enabled, the underlying WinSock functions are used.  While I tried
  hard to get the functionality as POSIXy as possible, keep in mind that
  a *fully* conformant implementation of getaddrinfo and other stuff is
  only available starting with Windows Vista/2008.

- Resolver functions (res_init, res_query, res_search, res_querydomain,
  res_mkquery, res_send, dn_comp, dn_expand) are now part of Cygwin.
  Applications don't have to link against minires anymore.  Actually,
  this *is* the former libminires.a.

- rcmd is now implemented inside of Cygwin, instead of calling the
  WinSock function.  This allows rsh(1)  usage on Vista/2008, which
  dropped this function from WinSock.

- Define multicast structures in netinet/in.h.  Note that fully
  conformant multicast support is only available beginning with Vista/2008.

- Improve get_ifconf.  Redefine struct ifreq and subsequent datastructures
  to be able to keep more information.  Support SIOCGIFINDEX, SIOCGIFDSTADDR
  and the Cygwin specific SIOCGIFFRNDLYNAM.  Support real interface flags
  on systems supporting them.

- Other new APIs: bindresvport, bindresvport_sa, iruserok_sa, rcmd_af,
  rresvport_af.  getifaddrs, freeifaddrs, if_nametoindex, if_indextoname,
  if_nameindex, if_freenameindex.

- Add /proc/net/if_inet6.

Device related changes:
-----------------------

- Reworked pipe implementation which uses overlapped IO to create
  more reliable interruptible pipes and fifos.

- Reworked pipe handling for better speed and better support for signal
  processing.

- Improved fifo handling.

- Detect when a stdin/stdout which looks like a pipe is really a tty.
  Among other things, this allows a debugged application to recognize that
  it is using the same tty as the debugger.

- Support UTF-8 in console window.

- Support up to 64 serial interfaces using /dev/ttyS0 - /dev/ttyS63.

- Support up to 128 raw disk drives /dev/sda - /dev/sddx.

- New API: posix_openpt.

Other POSIX related changes:
----------------------------

- Implement pthread_kill(thread, 0) as per POSIX.

- New API for POSIX IPC:
  Named semaphores: sem_open, sem_close, sem_unlink.
  Message queues: mq_open, mq_getattr, mq_setattr, mq_notify, mq_send,
  mq_timedsend, mq_receive, mq_timedreceive, mq_close, mq_unlink.
  Shared memory: shm_open, shm_unlink.

- Only declare expected functions in <strings.h>, don't include <string.h>
  from here.

- New APIs: asnprintf, dprintf, _Exit, vasnprintf, vdprintf, confstr,
  posix_madvise, posix_memalign, exp10, exp10f, pow10, pow10f, lrint,
  lrintf, rint, rintf, llrint, llrintf, llrintl, lrintl, rintl insque,
  remque, sys_sigabbrev, strcasestr, stpcpy, stpncpy, wcpcpy, wcpncpy,
  wcstol, wcstoll, wcstoul, wcstoull, wcsxfrm.

Security related changes:
-------------------------

- Getting a domain user's groups is hopefully more bulletproof now.

- Cygwin now comes with a real LSA authentication package.  This must
  be manually installed by a privileged user using the /bin/cyglsa-config
  script.  The advantages and disadvantages are noted in
  http://cygwin.com/ml/cygwin-developers/2006-11/msg00000.html

- Drop CYGWIN=ntea fake.

Miscellanous:
-------------

- Fallout from the long path names: If the current working directory is
  longer than 260 bytes, or if the current working directory is a virtual
  path (like /proc, /cygdrive, //server), don't call native Win32 programs
  since they don't understand these paths.

- On the first usage of a DOS path (C:\foo, \\foo\bar), the Cygwin DLL
  emits a scary warning that DOS paths shouldn't be used.  There's also
  the new CYGWIN=nodosfilewarning setting to disable that.

- Allow environment of arbitrary size instead of a maximum of 32K.

- Detect and report a missing DLL on process startup.

- Add /proc/registry32 and /proc/registry64 paths to access 32 bit and
  64 bit registry on 64 bit systems.

- Align /proc/cpuinfo more closly to Linux content.

- Optimized strstr and memmem implementation.

- Remove backwards compatibility with old signal masks (some *very* old
  programs which use signal masks may no longer work correctly).

- Numerous bug fixes.

- Probably a couple of entirely new bugs.

-- 
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

[Christopher Faylor]

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

[Corinna Vinschen]

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

[Christopher Faylor]

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

[Corinna Vinschen]

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

[Andrew Schulman]

> 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

[Brian Dessent]

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

Re: [HEADSUP] Start of Cygwin 1.7 release cycle

[Corinna Vinschen]

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

[Brian Dessent]

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.

Brian

Re: [HEADSUP] Start of Cygwin 1.7 release cycle

[Corinna Vinschen]

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

[Brian Dessent]

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

[Eric Blake]

-----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             ebb9@byu.net
-----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

[Corinna Vinschen]

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

[Eric Blake]

-----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             ebb9@byu.net
-----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

[Corinna Vinschen]

On Apr 15 06:26, Eric Blake wrote:
> -----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.

It's never too late...


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

[Troy Bull]

On Mon, Apr 14, 2008 at 8:11 AM, Corinna Vinschen
<corinna-cygwin@cygwin.com> 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