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...?
