Commit Graph

6 Commits

Author SHA1 Message Date
John Ericson
a1a1eb029b gcc/ng: put libstdc++'s library and headers where each belongs
Two halves of how the compiler finds libstdc++.

The library was not on the link path. `wrapCCWith` was given
`libcxx = libstdcxx`, which tells cc-wrapper where the C++ headers live
but does not put the library where a GNU compiler looks, so every C++
link failed with `cannot find -lstdc++`. Add `-B${libstdcxx}/lib`, as
libgcc, libssp, libatomic and libgomp already are.

The headers had the opposite problem: found too eagerly, by the wrong
language. libstdc++ deliberately ships headers named after C headers --
`math.h`, `stdlib.h`, `complex.h`, `stdckdint.h`, `stdbit.h`,
`stdatomic.h`, `tgmath.h`, `fenv.h` -- whose purpose is to shadow the C
ones when compiling C++. Installed into `$dev/include` they shadowed
unconditionally, since `libcxx` is a propagated target-target dep of
cc-wrapper and the setup hook puts that directory on the **C** include
path of everything built with the compiler. Under C, libstdc++'s
`<stdckdint.h>` is an empty shell, so its functions vanish:

    bash:      braces.c: implicit declaration of function 'ckd_sub'
    coreutils: randperm.c: implicit declaration of function 'stdc_bit_width'

Both build fine with monolithic GCC, whose libstdc++ headers live in
`include/c++/$ver` and are added by the g++ driver alone. Install them
into a sibling `include-cxx`, which keeps them off C's include path while
staying findable for C++; no version or target subdirectory is needed,
since the store path already separates one libstdc++ from another.

Assisted-by: Claude Code (Claude Opus 5)
2026-08-12 16:59:30 -04:00
John Ericson
120107d894 gccNGPackages: Replace some mailing list fetches with commits
A few patches of mine were just merged (yay!). Let's upgrade the
`fetchpatch` invocations from the original mailing list submission to
the accepted commit, accordingly.

I narrowed down the the files to patch because patching
autoconf-generated files will break, and is not needed because we are
regenerating those files anyways.
2025-12-10 14:05:03 -05:00
John Ericson
b58f15124b gccNGPackages_15.gcc: Fetch more patches
Another has been upstreamed, yay. And for the yet-to-be-merged ones on
top of it, we can fetch from the mailing list instead of vendoring in
Nixpkgs.
2025-08-23 01:46:19 -04:00
John Ericson
424f8f2abb gccNGPackages: Force regular dirs
Because we're building things separately, we don't need the fancy
lib/... namespacing tricks that GCC normally does to squeeze itself in
the FHS. We can just use the normal autotools libdir and include dir,
and the nixpkgs infra will sort everything out.

Where possible I submitted patches to the mailing list, and fetched
those. The ones I am vendoring are the residuals which I don't think are
ready for upstreaming yet. (I can imagine a further reworking upstream
such that we wouldn't need our own patches of that sort, but it would be
good to get the first crop merged first before discussing that.)
2025-07-21 15:40:34 -04:00
John Ericson
1840d4dbf0 gccNGPackages: Rework threading model patch based on feedback on IRC
Also clean up some comments, and avoid unnecessarily patching GCC
itself.
2025-07-13 12:51:54 -04:00
Tristan Ross
e51bc1ab23 gccNGPackages: init 2025-07-11 07:42:18 -07:00