[cfe-dev] [LLVMdev] New libc++ LLVM Subproject

OvermindDL1 overminddl1 at gmail.com
Thu May 13 23:35:31 PDT 2010


On Thu, May 13, 2010 at 11:11 AM, Christopher Jefferson
<chris at bubblescope.net> wrote:
>
> On 13 May 2010, at 17:57, Ahmed Charles wrote:
>
>>>> That is not set in stone at this point.
>>>
>>> Ah, I'm very glad to hear it!
>>>
>>>> An "abi-versioned" debug mode is another possibility.
>>>
>>> Sounds intriguing. :)
>>>
>>
>> VC2010 has pragma detect_mismatch for issues like this:
>> http://msdn.microsoft.com/en-us/library/ee956429.aspx I'm sure it wouldn't
>> be too hard to implement, if the entire toolchain is LLVM.
>>
>> I'm also curious as to why major versions of libstdc++ and libc++ (in the
>> future) would require ABI compatibility? Considering that MS breaks ABI
>> compatibility with each version, is there anything about the users of other
>> toolchains that make ABI compatibility a greater concern? My impression of
>> FOSS has always been that compatibility is an easier issue because the
>> source for most things is always available. Perhaps having a consistent ABI
>> versioning story for libc++ is something that should be looked into?
>
> Consider someone who has boost ( a large C++ library) installed on their linux / mac box.
>
> The standard library which boost was compiled against must be ABI compatible with the version used in every application using boost. Updates require either supporting multiple ABI-incompatible versions of the boost library and headers at the same time, or having a single "break the world", where every application is recompiled at the same time. I've had to do that before and it is very painful.
>
> Windows has tried harder to make this kind of thing work in the past, linux and mac less so.
>
> A fundamentally different approach to libraries, other than just dumping the boost headers in /usr/local/include/boost and the library in /usr/local/lib would be required to make this work.

That is why for all of my libraries, I use postfixes on the library
name, as Boost does (although mine are extended to include more then
Boost does.  Perhaps such a convention should be used here too.




More information about the cfe-dev mailing list