Re: Any plans to integrate just binutils‑gdb into GCC?

[unlvsur unlvsur]

it is not a waste of time because i need to run cross compilers on every of these platforms. i use my surface laptop7 windows on arm laptop, x86_64 windows, linux, oculus quest 2 (vr), android phone, x86_64 waydroid android emulator, m4 mac mini. raspi. WebAssembly. windows95 etc. Sometimes also need to test loongarch and riscv.

Every of these platform needs a compiler and often two with wine. Way too many

clang is not N^2 because runtimes do not need to get rebuilt every time. we only compile it by once while gcc has to rebuild every of them every time which is N*N.

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Arsen Arsenović <aarsenovic@baylibre.com>
Sent: Thursday, July 23, 2026 6:14:49 PM
To: unlvsur unlvsur <unlvsur@live.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>; gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>; binutils@sourceware.org <binutils@sourceware.org>
Subject: Re: Any plans to integrate just binutils‑gdb into GCC?

unlvsur unlvsur via Gcc-help <gcc-help@gcc.gnu.org> writes:

> The cross compiler approach (aka $target-gcc) ads another dimension which is mathematically a mess.
>
> For examples if you have N platforms, to build every possible combination,
> clang only has N combos (only needs the host). While gcc needs N^2
> (host*target). It just wastes computing resources to build each of them and it
> is a terrible mess. Just look at this. And this has been proven not only in
> theory but also in reality.

Having a compiler capable of generating code for a target does not
suffice to cross-compile to that target.

Indeed, LLVMs build system contains logic for building the runtime
libraries for other targets in much the same way as GCC does.

It is a waste of time to build all N^2 (or even N^3) combinations. So
don't do that.
--
Arsen Arsenović

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260723/f8f4761f/attachment.htm>