<div dir="ltr">Better only have 3.7 broken and 3.7.1 and onward working rather than break things multiple time. Vanilla 3.7 would need to be avoided by C API users. That is the most manageable option. Because C do not mangle signature, linking against the wrong version of LLVM won't cause any error, simply a program that segfault when calling the function.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-10 15:20 GMT-07:00 Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+Tom<br>
<br>
Sorry, I should have noticed that the C API changed.<br>
<br>
Looks like the fix is now merged in r247191. However, that means the<br>
API is changing between 3.7.0 and 3.7.1 :-/ I don't know if that's<br>
better or worse though.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 8, 2015 at 8:38 AM, Reid Kleckner via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> That really sucks. I wasn't aware that we fixed it after the branch point.<br>
> We could merge it and try to rush out a 3.7.1 release, but I think Hans is<br>
> all release-d out for now.<br>
><br>
> Given that we already broke compatibility in a released version of LLVM, I'd<br>
> be OK removing the compatibility hack and shipping the modified<br>
> LLVMBuildLandingPad. Personalities no longer live on landingpads.<br>
><br>
> On Sun, Sep 6, 2015 at 2:19 AM, deadal nix via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> During the dev in between 3.6 and the release of 3.7, the personality<br>
>> function was moved from the landingpad to the function itself.<br>
>><br>
>> During theses events, LLVMBuildLandingPad was changed, twice. The first<br>
>> time in a backward incompatible way, the second in a backward compatible<br>
>> way.<br>
>><br>
>> As things are now, the backward incompatible way is in 3.7 and the<br>
>> backward compatible in master.<br>
>><br>
>> Meaning master is backward compatible with 3.6 but not 3.7.<br>
>><br>
>> That is bad. If there is ever a plan for 3.7.1, that'd be great to cherry<br>
>> pick 7c898facbc5c707c77f25f7fd9b512a099af62a8 . Alternatively, master can be<br>
>> made compatible with 3.7 .<br>
>><br>
>> I'd like to add that having some actual testing for the C API would have<br>
>> prevented the whole confusion in the first place. I have a diff out to start<br>
>> moving in that direction: <a href="http://reviews.llvm.org/D10725" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10725</a> . The damn thing is<br>
>> out since June and nothing have moved since then.<br>
>><br>
>> If core devs are swaped and can't handle this, please delegate. I know<br>
>> there is some discussion about the state of the C API, but the thread is<br>
>> dead for weeks now, reasonable options have been presented, and I'm not sure<br>
>> what is expected to move things here. ALL alternative proposed in the thread<br>
>> pretty much are better than the status quo. I'm not sure what is expected<br>
>> for thing to move forward. It seems that cores devs just aren't using that<br>
>> API, but people actually using it or willing to work on it lack the power to<br>
>> do so.<br>
>><br>
>> Please make something happen. Sooner rather than later. I'm here to help,<br>
>> but really, if 2.5 month is what is required to get a test in, I'd be<br>
>> probably dead of old age before being able to have any significant impact.<br>
>> Same goes for others C API users.<br>
</div></div></blockquote></div><br></div>