Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3EBD3444.3020206@ece.gatech.edu>
Date: Sat, 10 May 2003 13:17:56 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dario Alcocer <alcocer AT helixdigital DOT com>, cygwin AT cygwin DOT com
Subject: Re: cygipc (and PostgreSQL) XP problem resolved!
References: <20030506174725 DOT GE1652 AT tishler DOT net> <3EB84F52 DOT 3020608 AT ece DOT gatech DOT edu> <20030507133326 DOT GA1824 AT tishler DOT net> <3EB9A54B DOT 8060500 AT ece DOT gatech DOT edu> <20030508135217 DOT GD512 AT tishler DOT net> <3EBB22F5 DOT 4000801 AT ece DOT gatech DOT edu> <1052541657 DOT 1675 DOT 5 DOT camel AT localhost> <20030510072110 DOT B12261 AT ns DOT helixdigital DOT com>
In-Reply-To: <20030510072110.B12261@ns.helixdigital.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/