cygipc (and PostgreSQL) XP problem resolved!

Sat May 10 17:37:00 GMT 2003

On Sat, May 10, 2003 at 07:22:31PM +0200, Corinna Vinschen wrote:
>On Sat, May 10, 2003 at 09:56:11AM -0700, Dario Alcocer wrote:
>> But what if the data types used by the existing functions are changed?
>> In other words, the old library has void FooFunc(off_t) where off_t is a
>> 4-byte quantity, but the new library uses an 8-byte off_t?
>>So what? If we change the name, we don't have anything like a
>transition period. It's just a new DLL which requires to rebuild
>all tools to work with. It's a whole new release.
>>My old 16/32 bit apps are still working fine under a new 32/64 Cygwin
>DLL. Your below example is a bad coincidence.
>>> For instance, the PowerTV tool chain uses GNUPro 99, which has an
>>Urgh, that's pretty old...
>>> ancient cygwin1.dll included. As long as I don't install the latest
>> Cygwin stuff, everything is ok. However, as soon as I install the
>>Are you talking about 1.3.22 or the current stuff from CVS?
>>> They way I've gotten around this issue is to binary edit the PowerTV
>> tool chain and change references to the cygwin1.dll to refer to
>> cygwin0.dll; this is a very ugly hack.
>>But it works. I recall having to do the same with a couple of tools
>when Cygwin changed from cygwinb20.dll to cygwin1.dll.

And even for cygwinb19, for that matter. From include/cygwin/version.h:
 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are
 incompatible. */
#define CYGWIN_VERSION_DLL_EPOCH 19
cgf
--
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/