On 6/5/25 4:17 PM, Thomas Schwinge wrote:
Hi!
On 2025-06-02T22:01:44+0530, Arijit Kumar Das <arijitkdgit.offic...@gmail.com>
wrote:
Umm, I don't think so. I've been building crosses with gcc for decades.
It should not be necessary, though it may sometimes be convenient.
Right. Similarly to how it's, for example, documented on
<https://www.gnu.org/software/gcc/simtest-howto.html>, also the build
instructions for GCC '--target=nvptx-none' that I gave Arijit use a
combined tree (just GCC plus newlib). You might indeed consider that's
just for convenience: let the top-level build system figure out at which
stage to build newlib, instead of manually doing C-only GCC
'--without-headers' etc., then build newlib with that, then rebuild full
GCC, etc.
Yea, neither solution is particularly ideal. The single tree build
stuff worked quite well in the past, but with the projects in different
repos it's gotten much harder to setup over the decades -- particularly
things like the host side includes.
I don't typically muck around with --with-headers because it requires a
reconfig/rebuild step. Nearly every target works with building the core
compiler (all-gcc), then building libgcc (all-target-libgcc). After
installing those you can build & install newlib, then proceed to build
the rest of the target libs without reconfiguring/rebuilding the compiler.
Though it's also the case that nvptx is one the targets I've never put
into my cross tester. nvptx is a bit special in various ways, of course.
If you feel there's a strong need, then you're going to have to make a
better case than what you've done above. Specifically you'd need to
start with why the standard cross build procedures don't work for nptx.
I'd consider the combined tree build one "standard cross build procedure"
(in addition to the "manual" one), but I also agree with Jeff that
special-casing just newlib isn't the way to go, given there are indeed
many more additional/optional packages that the top-level build system
can handle, as mentioned in
<https://inbox.sourceware.org/d463a70e-b586-40ce-b778-2e3d54b31...@gmail.com>.
(..., or, what about the long-standing idea that the top-level build
system should in fact be its own software package, instead of being
duplicated in GCC, binutils/GDB (and others?)... But we digress...)
More important would be to untangle the "include" subdirectory. We get
conflicts in there due to repo skew, which is mighty unfortunate.
Occasionally someone mentions git submodules as being helpful, but I've
never found them to actually simplify anything in practice.
Either way: Arijit, even if this one didn't get accepted, you've
successfully executed the process: congratulations on your first GCC
patch submission, on your own initiative -- way to go! :-D
Absolutely. The first patch feedback isn't dreaded the way it used to
be ;-) Don't get discouraged Arijit, great to have you contributing!
jeff
