Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.198.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=YOd5DTnWd0/r16gO6DEPvFpQCd0o7rdT7iAinEXfCLasm60h0qoL0mfKx0rINjhC9qlhkwAm+2ty+VIN9LOTbj+I599J0qKpRGbKgCAkaY5j4afkRJwj1TM6cRl2xXZtJmmMNqwlqnz6585dwosJ9Xlhl0yDUTqM4mml8xlih7M=
Message-ID: <4816A7D3.1020307@roguewave.com>
Date: Mon, 28 Apr 2008 22:45:07 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
References: <481161B6.2020305@roguewave.com>
 <001B1BAD-BC9B-41BF-9E09-D98F28CA0425@roguewave.com>
 <4815F4AD.2080400@roguewave.com>
 <58479750-45E0-424B-915D-03AF30CFCE69@roguewave.com>
 <4815FA4A.1030603@roguewave.com>
In-Reply-To: <4815FA4A.1030603@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

I see three options for how to deal with the ABI breakage on
Darwin:

   1) fix/revert the change that causes the ABI breakage,
      create new release candidate, and start a new vote, or

   2) document the breakage and a workaround in the README,
      create a new release candidate, and start a new vote, or

   3) open an issue for the ABI breakage, document how to work
      around it, but release -rc-3 unchanged.

If the problem is due to STDCXX-488 (1) should be pretty easy
to do and we could start the vote as early as tomorrow night,
and that would be my preference. Assuming the fix is isolated
to gcc/Darwin specific areas of the build infrastructure the
amount of re-testing would be small.

If it isn't easily fixable or if the fix is risky, we could
do (2) and still get the vote going by the end of tomorrow.
Fixing a README is trivial so the amount of retesting would
be minimal.

I'm not wild about option (3) because it goes against our
binary compatibility policy but given that Darwin is a best
effort platform I could be convinced to go with it if none
of the other alternatives was viable. It also is the most
expeditious approach.

Let me know your thoughts.

Martin Sebor wrote:
> Eric Lemings wrote:
>>
>> On Apr 28, 2008, at 10:00 AM, Martin Sebor wrote:
>>> Does this mean that stdcxx 4.2.1 isn't binary compatible with
>>> 4.2.0 on Darwin or that there is a problem with a dependency
>>> on some system library or something like that? (I can't tell
>>> for sure from the output you pasted below.) Either way, is
>>> this something new? (I don't recall it being mentioned when
>>> we did our binary compatibility testing two weeks ago.)
>>
>> It's most likely a problem with the way the library is built.
> 
> Could STDCXX-488 have something to do with it?
>   http://issues.apache.org/jira/browse/STDCXX-488
> 
>>
>> The first time I saw it was a couple weeks ago while testing binary 
>> compatibility.
> 
> And you waited to mention it until now because...?
> 
>