what's with the C++ <filesystem> extension?
René J.V. Bertin
rjvbertin at gmail.com
Mon Sep 19 18:33:01 UTC 2022
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 expanding the usage of that option to many more ports should be done carefully.
I see that with that port, executables link to $prefix/lib/libcxx/libc++.1.0.dylib instead of libc++.1.dylib but even with my current approach f using DYLD_INSERT_LIBRARIES to inject /opt/local/lib/libc++.1.dylib I notice that the dyld still also loads /usr/lib/libc++.1.dylib (in that order). However, to stick with my earlier comparison, I also see /opt/local/lib/libz.1.dylib and /usr/lib/libz.1.dylib being loaded (in that order) in zlib dependents.
I used DYLD_PRINT_LIBRARIES to see what's being "loaded", of course I cannot tell if the 2nd library will actually get used (not if nothing in the program uses symbols only available in the older library?). I may have to use the Activity Monitor for that.
Of course libz is a C library but in my experience it's even trickier to prevent issues when loading multiple versions of those.
I'm going to update my own port:libcxx to 9.0.1 (easier than to 12 because that apparently doesn't build the same way), install the link interface library and then see what happens (and report back here if I run into issues).
R.
More information about the macports-dev
mailing list