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 05:54:01PM +0200, Corinna Vinschen wrote:
> On Sat, May 10, 2003 at 07:21:10AM -0700, Dario Alcocer wrote:
> > On Sat, May 10, 2003 at 02:40:57PM +1000, Robert Collins wrote:
> > > Well, theres the API break coming up with cygwin1.dll - do it in sync
> > > with that, IMO.
> > Correct me if I'm wrong, but shouldn't cygwin1.dll be changed to
> > cygwin2.dll if the API is changing?
> Only if it's not a backward compatible change. Each new Cygwin version
> did already add new functions so the API minor number has been bumped
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?
The reason I ask is that I've seen binaries compiled for an older
cygwin1.dll run incorrectly or crash when dynamically linking against a
For instance, the PowerTV tool chain uses GNUPro 99, which has an
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
latest cygwin1.dll, the PowerTV gcc/binutils cease to function
correctly. I suspect it has something to do with the Cygwin API and/or
ABI changing, and since the Cygwin DLL filename is exactly the same, it
loads the new library instead of using the old one.
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, and I don't recommend it. But it
does serve to highlight the kinds of problems people might be running
into in the field.
Dario Alcocer -- Sr. Software Developer, Helix Digital Inc.
firstname.lastname@example.org -- http://www.helixdigital.com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html