Re: cygipc (and PostgreSQL) XP problem resolved!

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Sat, May 10, 2003 at 01:32:00AM -0400, Charles Wilson wrote:
> Caveat to the caveat: this analysis ONLY applies if the compiled object 
> (DLL, static lib, executable, etc) actually USES one of the symbols 
> whose typedef has changed.  Currently, the list of affected packages is 
> pretty small (zlib is one).

You can go a step further:

  ...actually USES one of the symbols IN IT'S API...

> Assuming the above is all correct, then I have some questions (and 
> perhaps these should be addressed on cygwin-apps)
> 
> 1) NOT counting key_t, what symbols do I need to grep for in my packages?
>   _off32_t _off64_t

These have changed to _off_t and _off64_t as in newlib.

>   acl32 aclcheck32 aclfrommode32 aclfrompbits32 aclfromtext32
>   aclsort32 acltomode32 acltopbits32 acltotext32 facl32
>   fgetpos64 fopen64 freopen64 fseeko64 fsetpos64 ftello64
>   _open64 _lseek64 _fstat64 _stat64 mknod32
> And what else?

Well, you have to grep for the above symbols but without the 32/64 suffix.
If your package uses these symbols and/or the types off_t, uid_t, gid_t,
fpos_t, dev_t, blkcnt_t, struct group and struct stat, you're sorta candidate.

If your package has an API which uses one of these types, structs created
with one of these types or derivated types, you're a sure candidate.

According to the above, if the package is using these symbols internally
but doesn't use them as, say, parameter to an exported function, you have
a bit more time for the change.  In that case, your DLL is still 32 bit
but no immediate problems will occur.  For instance, in my local sandbox
I'm using a 64 bit ssh with a 32 bit openssl DLL.

> 2) What *exactly* was the compatibility magic that Corinna did?  Should 
> similar magic be applied to key_t (assuming a transition to 64bit key_t 
> is desirable at this point?)

Have a look into cygwin/include/cygwin/type.h.  Example:

  #ifndef __uid_t_defined
  #define __uid_t_defined
  typedef unsigned short __uid16_t;
  typedef unsigned long  __uid32_t;
  #ifdef __CYGWIN_USE_BIG_TYPES__
  typedef __uid32_t uid_t;
  #else
  typedef __uid16_t uid_t;
  #endif
  #endif /*__uid_t_defined*/

The define __CYGWIN_USE_BIG_TYPES__ will only be defined with the new header
files coming with the new DLL (it is this way already in the snapshots).

You don't have to use new functions (e. g. lseek64 instead of lseek) but
instead, just recompile and your application will magically use the new
64 bit off_t and the lseek64 function while its code is actually calling
lseek.

If you want to create a lib which is also backward compatible like the
Cygwin DLL, you have to use a similar mechanism as Cygwin does.  Basically
the idea is to keep the old "foo" function around and create a new "foo64"
function.  Mostly it makes sense to implement the functionality in "foo64"
and to call it from "foo" with just a type conversion.  So the functionality
isn't duplicated.

Then create a DLL which exports both functions.  At the same time create
a .dll.a link stub which only has the "foo64" function exported but --
that's the clue -- aliased to "foo".  If you now link an application
against your new lib, it will automagically link against "foo64" instead
of "foo" while old apps still are linked against "foo".  The key_t problem
would have to be solved as above:

  #ifndef __key_t_defined
  #define __key_t_defined
  typedef unsigned short __key16_t;
  typedef unsigned long  __key32_t;
  #ifdef __CYGWIN_USE_BIG_TYPES__
  typedef __key32_t key_t;
  #else
  typedef __key16_t key_t;
  #endif
  #endif /*__key_t_defined*/

But it's some work.  So in general it might be a good idea to just
recompile and repack the DLLs with new release number to be plain 64 bit
instead of creating a lot of fat binaries (oh, we're not on Apple, I
guess).  This problem only arises in DLLs which support interapplication
communication of some sort and which depend on the size of system types
in their API or message definition.

However, other problems will arise, e. g. packages which implicitely
expect off_t to be not bigger than sizeof long and that sort of stuff.
Blerch.

> 3) What sort of timeline are we looking at for me to recompile zlib and 
> have a new cygwin1.dll-compatible version ready to go; ditto cygipc (IF 
> it is determined that adding cygipc to the dist is a good idea -- so far 
> we've only heard from a few folks on this, counting cgf's rather 
> diffident proposal)

We will release 1.5.0 as a test release first.  Next step is to rebuild
important DLLs (libz etc) and tools (ls, id, etc).  We don't have a fixed
timeline and we expect some... friction in this process but having at
least a backward compatible Cygwin DLL should make it not too tough a
process (knock on wood).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/