This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygipc (and PostgreSQL) XP problem resolved!

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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]