[LLVMdev] Preferring to use GCC instead of LLVM

[Owen Anderson]

On May 13, 2008, at 12:49 AM, kr512 wrote:
> Owen Anderson wrote:
>> The OP was implying that LLVM is incomplete because it
>> depends on GCC in the backend, which is incorrect.  It
>> depends on binutils,
>
> Alright, so I used the wrong name.  I said GCC but I should
> have said binutils.  My original point remains valid -- LLVM
> is an incomplete backend because by itself it is unable to
> generate a ready-to-execute .EXE or .DLL file.
>

By your definition, GCC is incomplete as well.  Of course, the  
solution that is typically employed for GCC installations is to bundle  
the necessary parts of binutils with it, for instance in Apple's  
developer tools package.  There's nothing particularly stopping you  
from having your installation package include copies of gas and ld,  
and would result in an LLVM that is just as "complete" as GCC.

> And binutils is not necessarily available on the customer's
> computer.  Do all Linux and BSD distributions include it
> preinstalled?

No, they don't.  I know, for example, that Ubuntu doesn't.  But in its  
packaging mechanism (apt), it pulls them in as a dependency when you  
install GCC.  The appropriate thing to do would be to make them a  
dependency of LLVM as well.

> Owen Anderson wrote:
>> 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.
>
> That attitude is very much hurting LLVM's popularity and
> adoption in real-world situations.
>

You're welcome to think that, and I'm welcome to think that your  
demands are unrealistic.

When I write a text editor, do I first need to write an OS kernel to  
run it on?  How about disk device drivers?  Display drivers?  Of  
course not.  I build on tools that already exist.  Similarly,  
compilers build on other tools like linkers and assemblers.  Of  
course, they typically hide this dependency by including the linker/ 
assembler inside their installation package.  Which is exactly what  
you should be doing.

>> The fundamental problem is that both executable formats
>> and linking problems are EXTREMELY platform specific, so
>> it's typically best to leave it up to the system tools.
>
> But these system tools do not exist (or are not installed)
> on all relevant/significant customer computers.
>

Incorrect.  They exist for all of the relevant platforms, or else  
development on that platform would be impossible/extremely difficult.   
You just need to distribute them as part of your installation package  
(or via a dependency mechanism on systems like Ubuntu that use them).


> LLVM needs to sever its backend ties with
> MinGW/Cygwin/GCC/binutils.  Because if we are going to use
> the hacked bastard child of LLVM combined with
> MinGW/Cygwin/GCC/binutils, then we may as well just use the
> normal version of MinGW/Cygwin with GCC and not bother with
> the added complication of LLVM.
>

See, this is the part where you throw people.  You keep stating that  
you really want to use LLVM, but this kind of statement makes it sound  
like you don't really care.

I'm going to let you in on a reality of open source development: if  
you really particularly want some feature, you might have to end up  
writing it yourself.  This is true whether you're talking about LLVM,  
GCC, the Linux kernel, or emacs.  Showing up and demanding that they  
be done for you isn't going to get you anywhere, particularly since  
plenty of users seem to get along fine w/o what you're demanding.

In all sincerity, I hope you get something that will work for you,  
whether it's LLVM or something else.  But I do think your expectation  
that we're all going to drop what we're doing in order to embark on  
multi-year projects to replace underlying system tools when plenty of  
other users have figured out how to work with the existing ones is  
unrealistic.

Good luck,

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080513/541e252c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4260 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080513/541e252c/attachment.bin>