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
