As per the ticket, I noted system apps (like iCal) crash when I upgraded the
libc++ on Lion to the one we supply with libcxx, so that, for me, is
unreliable. I didn’t try every system or every app of course.
Mixing libc++ versions in one executable’s dylib space crashes unpredictably
On Monday September 19 2022 18:41:54 Chris Jones wrote:
>Note though the expose of that feature, on newer systems at least, is very
>much limited at the moment and I stand by my statement that mixing multiple
>c++ runtimes, unless done very very carefully, is a recipe for problems. So
> On 19 Sep 2022, at 6:12 pm, René J.V. Bertin wrote:
>
> never mind, I discovered port:macports-libcxx and the trac ticket that led
> to its creation (which mentions the filesystem extension...)
>
> The port does exactly what I think should be done, but at a port-specific
> level.
> On 19 Sep 2022, at 3:08 pm, René J.V. Bertin wrote:
>
> On Monday September 19 2022 13:56:01 Chris Jones wrote:
>
>> But anyway, I m sure you will think you are right, so please feel free to
>> experiment on your own system, as you get to own the pieces there once it
>> breaks.
>
>
never mind, I discovered port:macports-libcxx and the trac ticket that led to
its creation (which mentions the filesystem extension...)
The port does exactly what I think should be done, but at a port-specific level.
R.
On Monday September 19 2022 13:56:01 Chris Jones wrote:
>But anyway, I m sure you will think you are right, so please feel free to
>experiment on your own system, as you get to own the pieces there once it
>breaks.
What do you think happens when you upgrade an OS but not ALL your other
> On 19 Sep 2022, at 11:53 am, René J.V. Bertin wrote:
>
> On Sunday September 18 2022 23:57:53 Chris Jones wrote:
>
>> Follow the above at your own risk.
>
> As I said, there is no need to update the system libc++ on systems that
> already have it; `port:libcxx` can (could) provide a set
On Sunday September 18 2022 23:57:53 Chris Jones wrote:
>Follow the above at your own risk.
As I said, there is no need to update the system libc++ on systems that already
have it; `port:libcxx` can (could) provide a set of libraries under ${prefix}
that override the system ones for dependent
> On 18 Sep 2022, at 11:58 pm, Chris Jones wrote:
>
>
>
>
>>> On 18 Sep 2022, at 1:29 pm, René J.V. Bertin wrote:
>>>
>> Hi,
>>
>> Building C++ code that does
>>
>> #include
>>
>> I get either a file-not-found error or a bunch of errors that the functions
>> are 10.15+ only. What's
> On 18 Sep 2022, at 1:29 pm, René J.V. Bertin wrote:
>
> Hi,
>
> Building C++ code that does
>
> #include
>
> I get either a file-not-found error or a bunch of errors that the functions
> are 10.15+ only. What's with that?
Seems pretty clear to me…
> If the implementation is provided
On Sunday September 18 2022 14:29:07 René J.V. Bertin wrote:
>On more recent systems that have a stock libc++ one can install `port:libcxx`
>with the binaries under $prefix . I have been doing that for years so all
>MacPorts executables use it, and that has never caused any ABI issues with
Hi,
Building C++ code that does
#include
I get either a file-not-found error or a bunch of errors that the functions are
10.15+ only. What's with that?
If the implementation is provided by libc++, isn't this something that could be
patched? Shouldn't require any external dependencies on
12 matches
Mail list logo
