> On Mar 13, 2024, at 4:07 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > >> 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.
What I rather meant is that Macports cannot handle that properly, since it is kinda hardcoded to use clang and libc++ on anything besides powerpc. I think we have a few older ports broken now, which required libstdc++. > 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`. AFAIK nobody tested GCC with libc++, neither in upstream nor in Macports, so it is not overly surprising that it does not work :) It is worth opening a ticket on GCC Bugzilla, if there is none yet for this issue. > 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). On a side note, for older Intel systems it is not even clear if libc++ is a better choice.
