On Wednesday March 13 2024 03:44:17 Sergio Had wrote: >Which OS are we talking about?
10.9.5 but that what matters here is that it's a libc++-based OS version. >Building against libstdc++ is broken for Intel Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ from GCC13 and that works. Of course it's easy to break the application if you end up mixing libstdc++ with libc++. In fact, if libstdc++ were broken GCC itself wouldn't work: it can only be built against that C++ runtime. (You can imagine how complex my bootstrap flags are to build a gcc that uses libc++ by default ;) ) Yes, gcc 13 isn't yet compatible with libc++, but the current -stdlib=libc++ implementation also fails (for me) on Qt5 (5.9) projects because libc++ has its own version of (IIRC) cstddef and raises an error if the one from GCC has already been included. To avoid that the c++/v1 directory must be before the GCC C header dirs in the search list, and not after as GCC currently does it. I've signalled that, and you can achieve the same thing with the traditional recipe to use libc++ with GCC: `-nostdinc++ -isystem/path/to/c++/v1`. FWIW, I patched GCC 6 and 7 back in the day to add a `-stdlib=` argument. I don't really know why I didn't use it, probably because the concurrent clang versions were still faster. That's no longer the case; GCC 12 is about as slow as clang 12 (but a lot more modern, with full, non-buggy C++20 support, and apparently less resource hungry). I've caved and activated gcc12+stdlib_flag (i.e. the stock MP build) which will do what I want ATM without need for additional flags. I'm now rebuilding lld-17 with its minimal libLLVM & family. That build failed with -stdlib=libc++ (so gcc12 isn't perfectly compatible with any of our libc++ implementations I tested either) but the initial estimate is that the build would have completed in about 2/3 of the time as it would take with clang 16. Lld looks to depend on libc++ only through port:icu via libxml2 which is pure C afaik so the C++ runtimes should remain separated in this case. We'll see... anyway the only reason I'd keep the build is if it's a lot faster or a lot more compact than the one with clang 16. I mostly just want to compare build times on a hefty project. R.
