LibCxxOnOlderSystems - and more software that is pushing for gcc

[Chris Jones]

> On 25 Sep 2016, at 3:32 pm, Yongwei Wu <wuyongwei at gmail.com> wrote:
> 
> 
> 
>> On 25 September 2016 at 22:21, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>> 
>> 
>> 
>>> On 25 Sep 2016, at 2:49 pm, Yongwei Wu <wuyongwei at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On 25 September 2016 at 21:35, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>> 
>>>> 
>>>>> On 25 Sep 2016, at 2:25 pm, Brandon Allbery <allbery.b at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Sun, Sep 25, 2016 at 8:29 AM, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
>>>>>> What is happening exactly on my MacPros running 10.11, I wonder? Software installed by macports on 10.11 is using clang++ (mostly) and g++ (sometimes). clang++ is linking against libc++, and g++ is presumably  linking against libstdc++ as that is what it does -- yet there appear to be no visible issues...and these libraries find each other. 
>>>>> 
>>>>> An additional complication is that it's not using the same libstdc++: it's using the GPL3 one with C++11 support, not Apple's GPL2/pre-C++11 one. So potentially the clash here is between the two libstdc++ versions, not libstdc++ and libc++.
>>>> 
>>>> Indeed, mixing two different libstdc++ runtimes has the same sort of issues as mixing libstd++ with libc++.
>>> 
>>> I actually do not think this is normally an issue. If the dynamic libraries​ manage the lifetime of their own object, i.e. do not do something like creating an object in a library but not providing a function to destroy it (so that the application needs to delete it), bad things should not occur. At least that is the only case I am aware of. (I encountered this kind of problems on Windows, which was even worse, as each new release of MSVC brought in a different C/C++ runtime, which can also be either static or dynamic.)
>> 
>> Its exactly the same situation as with libc++ v libstdc++. There are ways it can be ok and ways you can run into problems. The only guaranteed way (I know of) to not have issues is not to do it.
> 
> ​My point is that a well-designed application/library should not do this. And if it did it, problems might have occurred long ago (esp. on Windows, supposing a Windows port exists). If things are going on well so far, we probably do not need to worry much. At least I do not see what we can do to help the case at the moment.

You are missing my point. For a single application, built by one developer it might be possible to avoid (I would still argue its a bad design choice). We are talking about Macports though, which is a very different beast. Its an ecosystem of many libraries and applications. There is no way to police it to make mixing work, so the only solution is to not do it.

> 
> -- 
> Yongwei Wu
> URL: http://wyw.dcweb.cn/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160925/bc075882/attachment.html>