This is the mail archive of the
mailing list for the Cygwin project.
Re: cygipc (and PostgreSQL) XP problem resolved!
On Sat, May 10, 2003 at 04:30:35PM +0200, Ralf Habacker wrote:
> I think at least for a specific migration time there should be a compatibility
> define (for example __CYGWIN_NO_BIG_TYPES__) to ensure, that c++ applications
> based on older packages could be build. Currently I can't see, if this is all to
> do, so please see this as a basic proposal.
> #if defined(__CYGWIN32__) || defined(__CYGWIN__)
> #define __FILENAME_MAX__ (260 - 1 /* NUL */)
> #define _READ_WRITE_RETURN_TYPE _ssize_t
> #ifndef __CYGWIN_NO_BIG_TYPES__
> # define __LARGE64_FILES 1
> # define __CYGWIN_USE_BIG_TYPES__ 1
> # define __LARGE64_FILES 0
> # define __CYGWIN_USE_BIG_TYPES__ 0
But that won't work. If you want to build apps using qt build under
old Cygwin, you need an old libcygwin.a as well. Otherwise your apps
would use small types while they get linked to the new functions expecting
the big types. That smells like becoming a lot of trouble.
What would help is a libcygwinOLD.a or something to link applications
to the old functions... however, that's not intendend. We don't want
to extend the lifetime of the old type'd interface artifically. It's
obviously one of the goals to have bad headaches for a short period of
time for the sake of having a really short transition period. Old
applications should run with old libs, that's ok, but new applications
should always be build against new libs. Therefore we *want* you as
a library maintainer to be forced a bit to release the new libs ASAP.
We're suffering from too small datatypes already too long.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:firstname.lastname@example.org
Red Hat, Inc.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html