Owen Anderson <firstname.lastname@example.org> writes:
That's only a convenience. GCC generates assembly code too and calls
the assembler and linker as part of it's execution. You are perfectly
able to call the assembler & linker yourself.
This means that LLVM requires an assembler and linker. Call it GCC or
binutils, it is irrelevant. The OP point is that LLVM is not a
self-sufficient tool on this aspect.
Actually, I think Bill's right on target. The OP was implying that
LLVM is incomplete because it depends on GCC in the backend, which is
incorrect. It depends on binutils, _which GCC also depends on_. Thus
LLVM is certainly no less complete than GCC in that sense.
There is a culture schism here. The Windows folks are accustomed to
monolithic packages that does all the work. For Unix folks, having
"tool-chains" is the natural way. For a Windows folk, having extra
requirements goes against what he is accustomed to. If LLVM is
perceived as a backend, but it fails short into producing the final
result, the typical Windows folk will be disappointed.
The OP talks about GCC because that's what he sees, irrespectively of
the other tools behind. In Windows, installing GCC implies installing
binutils, either via MinGW or Cygwin. This is deeply rooted into the
Windows development culture: a "compiler" has all needed parts for
creating an executable. They talk about the Visual C++ compiler, or the
Borland compiler, never about the Borland compiler and linker.
I think the point is that implementing our own linker is definitely
beyond the purview of LLVM, and implementing our own object file
writer/assembler is honestly pretty low on the priority queue. GCC,
the primary alternative, also depends on these things, so having them
would be a competitive advantage, not a requirement for parity.
Absolutely agreed. I'm just trying to explain from where the OP (seems
This does not *comes* with MS Windows. It is a separate download,
depends on more downloads (Visual C++ Express Edition) and is for
non-commercial use only. Furthermore, you can't re-distribute it.
From what I read, it's included with copies of Visual Studio. I
assume that a paid copy of Visual Studio (as opposed to the free
Express edition) includes a version that's licensed for commercial
Exactly. And this is very different from the GNU/Linux and BSD case,
where the existence of a compiler, assembler and linker along the OS is
considered a "reasonable requirement" and part of the standard
installation in most cases. If the OP plans to deploy his compiler on
Windows, he can't assume the existence of an assembler/linker on most
user's machines. He becomes dependent of third-party packages, hence
LLVM is not a "complete backend" from his (limited) point of
view. (Leaving aside the fact that a compiler backend is not required to
generate executable files, but his insistence on this point is related
to the "monolithic package" paradigm I mentioned above).
Additionally, LLVM's support for Win32 outside of MinGW/Cygwin is
... spotty at best.
Sure. And, AFAIK, even if you want to use MASM, you need to add support
for his assembler format to LLVM.
And in those environments, the competition is, once again, GCC, which
still depends on gas and ld.
The fundamental problem is that both executable formats and linking
problems are EXTREMELY platform specific,
Agreed. I'm just trying to explain that, from the POV of the OP's
culture, the demands he expressed are quite reasonable. This narrow view
of the world and being... ummmh... too demanding, are the only problems
with the OP message
Expect more messages like this as LLVM becomes more popular outside
professional and academical circles.