Re: inserting -stdlib=libstdc++ into cxxflags
BTW, did you ever run into trouble with libstdc++'s "new ABI" (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) ? R.
Re: inserting -stdlib=libstdc++ into cxxflags
sorry, clang-11-bootstrap > On Mar 23, 2024, at 00:01, Ken Cunningham > wrote: > > the clang-10-bootstrap port builds against libstdc++ now. > > K
Re: inserting -stdlib=libstdc++ into cxxflags
the clang-10-bootstrap port builds against libstdc++ now. K
Re: inserting -stdlib=libstdc++ into cxxflags
On Sunday March 17 2024 03:44:00 Sergey Fedorov wrote:
>> but if libc++ 5 was maybe still a bit faster overall than libstc++ the
>situation is now rather reversed though differences remain small
I take that back, the differences aren't always small!
I realised that the so-called "native" benchmark from the libcxx source tree
could be used with the libstdc++ from (currently) port:libgcc13. It took some
time to figure out how to inject the `-stdlib=macports-libstdc++` argument
properly but once I got that working on Linux it transferred without further
ado to Mac.
These results just in. Libc++ and all benchmarking code built with
`clang++-mp-12 -O3 -march=native -flto`.
libstdc++ is indeed consistently faster. Usually by not much (though the
differences in kernel time spent can be relatively important):
```
> build/libcxx/benchmarks/algorithms.partition_point.libcxx.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.13, 1.27, 1.34
89.198 user_cpu 0.907 kernel_cpu 1:30.11 total_time 99.9%CPU {93360128M 0F
226542R 0I 0O 0k 0w 445c}
> /build/libcxx/benchmarks/algorithms.partition_point.native.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.42, 1.35, 1.34
75.612 user_cpu 0.911 kernel_cpu 1:16.53 total_time 99.9%CPU {102424576M 0F
229228R 0I 0O 0k 0w 504c}
```
```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1
> --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.75, 1.70
220.386 user_cpu 2.961 kernel_cpu 3:43.50 total_time 99.9%CPU {79626240M 0F
542726R 0I 9O 0k 154w 3502c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1
> --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.66, 1.79, 1.67
190.844 user_cpu 2.615 kernel_cpu 3:13.50 total_time 99.9%CPU {89800704M 0F
504812R 0I 9O 0k 149w 1942c}
```
But observe this, as far as I understand a "small" version of the above
benchmark that seems to highlight a huge overhead in libc++:
```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1
> --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.61, 1.37, 1.36
1947.681 user_cpu 221.754 kernel_cpu 36:10.22 total_time 99.9%CPU {78262272M 0F
1503675R 0I 9O 0k 152w 22829c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1
> --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x2)
L1 Instruction 32 KiB (x2)
L2 Unified 256 KiB (x2)
L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.42, 1.36
1056.593 user_cpu 8.435 kernel_cpu 17:45.51 total_time 99.9%CPU {78917632M 0F
1458187R 0I 9O 0k 154w 12805c}
```
Here the library from the "bloated" GCC is twice as fast overall, and uses
almost 30x less kernel CPU time!
I see the same on Linux.
This makes me wonder if shouldn't try building llvm+clang against
macports-libstdc++ . I have already managed to do so with lld-17 (only depends
on libc++ via libxml2, and turns out to be "safe to mingle"). Newer clang
versions build against their own libc++ even on Linux (when building with
clang) so that suggests the code has been designed to separate the possibly 2
C++ runtime versions that get linked. It would probably be impossible to use
the resulting libLLVM or libclang in dependent ports but maybe the performance
increase might be worth it.
R
Re: inserting -stdlib=libstdc++ into cxxflags
> On Mar 13, 2024, at 4:07 AM, René J.V. Bertin 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.
Re: inserting -stdlib=libstdc++ into cxxflags
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.
Re: inserting -stdlib=libstdc++ into cxxflags
Which OS are we talking about?
Building against libstdc++ is broken for Intel and arm64, I believe, though it
should be fixable. But the problem is not passing the flag, but broken Apple
headers, it seems.
I managed to build some ports like CMake and a few others against libstdc++ on
Sonoma arm64, but kinda gave up, since too much stuff is broken, and there is
no immediate advantage in the switch.
I have this in macports.conf: `cxx_stdlib macports-libstdc++` (on Sonoma).
However you may need to pass both cxxflags and ldflags manually.
On PowerPC it is the reverse: building against libstdc++ is the default and
works fine, building against libc++ is very experimental and will likely need
fixups. Also, it requires enabling stdlib_flag variant for gcc and making it
use libcxx-powerpc port instead of clangs.
P. S. There is a bug in gcc13 which prevents it working correctly with libc++
headers (regardless of the arch, I think), should be fixed in upstream but
perhaps not in Macports, but gcc12 should be fine.
> On Mar 13, 2024, at 3:32 AM, René J.V. Bertin wrote:
>
> Hi,
>
> I've been tinkering a bit with a personal GCC12 build patched to use libc++
> by default, and now find myself unable to build against libstdc++.
>
> `configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out
> somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears
> not to have any effect either. I'm not seeing any warnings in the logfile,
> which is surprising (and rather bad practise IMHO).
>
> What am I missing here, and what backdoor(s) could I use? I notice that
> CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet
> checked if "base" preserves its settings when initialising it (have been
> assuming it won't). With autoconf-based projects one can set `configure.cxx
> ${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based
> projects...
>
> Thanks,
> R.
inserting -stdlib=libstdc++ into cxxflags
Hi,
I've been tinkering a bit with a personal GCC12 build patched to use libc++ by
default, and now find myself unable to build against libstdc++.
`configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out
somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears
not to have any effect either. I'm not seeing any warnings in the logfile,
which is surprising (and rather bad practise IMHO).
What am I missing here, and what backdoor(s) could I use? I notice that
CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet
checked if "base" preserves its settings when initialising it (have been
assuming it won't). With autoconf-based projects one can set `configure.cxx
${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based
projects...
Thanks,
R.
