cygipc (and PostgreSQL) XP problem resolved!

[Charles Wilson]

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?

Sortof, and not always.  This is one of the 'not always' cases.

cygwin doesn't use the libtool numbering scheme, but it intrinsically 
obeys it.  Remember, DLLVER is only concerned with runtime 
compatibility, not compile time compatibility.

In libtool, versions are expressed with three cumbers, c:r:a 
(current:revision:age).

1) if you change the libraray code AT ALL:
    r = r+1

2) if you ADD, REMOVE, or CHANGE any part of the API:
    c = c+1
    r = 0

    2a) if you ADD to the API,
        a = a+1
    2b) if you REMOVE or CHANGE the API
        a = 0

DLL version number == c - a.

Thus, if you work thru the rules above, then
   if you simply ADD to the API, c - a remains constand == DLLVER 
doesn't change
   if you CHANGE the signature of a function, or REMOVE a function, then 
c - a changes == DLLVER changes.

Technically, Corinna's change only ADDs to the API, so the DLLVER 
doesn't need to change (futher, runtime compatibility is unaffected). 
It's only compile-time compatibiltiy that is affected right now -- in 
libtool speak, that is allowed to happen on a c:r:a -> c+1:0:a+1 transition.

IOW, users need not worry.  developers/maintainers may need to worry, if 
they are unlucky.  I am unlucky.  Lucky me.

--Chuck



--
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/