inserting -stdlib=libstdc++ into cxxflags
Sergio Had
vital.had at gmail.com
Tue Mar 12 20:37:51 UTC 2024
> On Mar 13, 2024, at 4:07 AM, René J.V. Bertin <rjvbertin at 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.
More information about the macports-dev
mailing list