Ok, this is my "Welcome to 1.5.0" message for package maintainers. I hope it answers most questions. If not, feel free to ask on cygwin-apps.
What is that 64 bit babble? --------------------------- Up to release 1.3.x, Cygwin had some limitations which were induced by too small datatypes: off_t was 32 bit, so not allowing to seek more than 2 Gigs and to show filesizes over 2 Gigs correctly. This has been changed to 64 bit, allowing to access all files correctly. fpos_t, ditto. blkcnt_t, used in struct stat, change from 32 to 64 bit for the same reason. ino_t, changed from 32 to 64 bit to allow 1:1 mapping of Windows file index numbers to inode numbers. uid_t and gid_t were 16 bit which result in problems mapping Windows NT user accounts to uids and gids. Changed to 32 bit. All related structures (FILE, struct stat, struct dirent, struct group) have been changed accordingly. Ditto all related functions (lseek, fseeko, stat, setuid, getgid, ...). How does that all work? ----------------------- First of all, all affected types have been defined twice, once for releases up to 1.3.22, once for 1.5.0ff. The usage of the new datatypes is controlled by a define in include/cygwin/config.h called __CYGWIN_USE_BIG_TYPES__. If this define exists, the new bigger datatypes are used. Note that this define is *not* under package developer control! It marks the switch from small to big datatypes in conjunction with the used import library. To make this clear: If you build an application with header files from 1.3.22 and libcygwin.a from 1.5.0, the result is very likely broken. And vice versa, if you build an application with 1.5.0 headers and 1.3.x libcygwin.a the result will probably not work. If you need to build applications running under 1.3.x, keep the 1.3.x headers and import libraries. As I mentioned above, Cygwin is using the big datatypes internally throughout. So, how is it possible that an old application can call a function, say lseek(), with a 32 bit off_t and a newly build application calls it with a 64 bit off_t? The internal implementation of lseek looks like this: _off32_t lseek(int fd, _off32_t offset, int whence) { return (_off32_t) lseek64 (fd, (_off64_t) offset, whence); } _off64_t lseek64(int fd, _off64_t offset, int whence) { [actual implementation] } lseek and lseek64 are both exported from the Cygwin DLL. Old applications still use the lseek entry point since they don't know better. Newly build applications on the other hand will use the lseek64 entry point directly. But how do they know? That's done at link time. The new libcygwin.a import library translates call to lseek to calls to lseek64 transparently. Applications don't have to know anything, they just get it for free. How does that affect applications? ---------------------------------- All current applications, build under Cygwin versions prior to 1.5.0 don't have access to the new 64 bit world. These applications will run, but they are still limited as before. Newly build applications are on the bright side of life. They do use all the new types automatically. But this transition of applications has to be done carefully. Applications build under 1.5.0 will not run under older Cygwin releases! Again, please note that the new datatypes are used automatically. There isn't any choice between e.g. a off_t with 32 bit and a off64_t with 64 bit and no corresponding functions as stat and stat64. Building under 1.5.0 means, off_t is 64 bit now. stat is expecting a struct stat with 64 bit off_t. Full stop. No compile time options. All or nothing. Well, you got the idea, I guess... Think about it. Especially if you're maintaining an older package (my own inetutils is a good candidate) it might require some code changes. To stick with off_t as example, old packages often expect off_t to fit well into long. printf("%ld", off); will print... interesting... values. Other similar traps are possible. How does that affect Cygwin package maintainers? ------------------------------------------------ It's important to know, if the package depends on other external libraries besides Cygwin itself. Packages only dependend on Cygwin can be build immediately and will run as expected (iff they are prepared to handle 64 bit types correctly). Packages which depend on external libs should be newly build only if all external libs have been newly build first. E.g. vim depends on ncurses. So I, the vim maintainer, will wait with creating a new vim version until Charles, the ncurses maintainer, has created a new ncurses version. This means, the package maintainers of libraries, especially those which provide DLLs should build a new version of their packages as soon as possible. Only with all libs finished, we can finally migrate the whole Cygwin net distro to 64 bit. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc.