This is the mail archive of the
mailing list for the Cygwin project.
HEADSUP package maintainers: Welcome to Cygwin 1.5.0
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 10 Jul 2003 22:50:53 +0200
- Subject: HEADSUP package maintainers: Welcome to Cygwin 1.5.0
- References: <20030704174759.GA28901@redhat.com>
- Reply-to: cygwin-apps at cygwin dot com
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.
blkcnt_t, used in struct stat, change from 32 to 64 bit for the same
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)
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.
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
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
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.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:firstname.lastname@example.org
Red Hat, Inc.