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.
