[LLVMdev] Preferring to use GCC instead of LLVM

David Vandevoorde daveed at vandevoorde.com
Tue May 13 05:44:35 PDT 2008


On May 13, 2008, at 6:39 AM, kr512 wrote:
[...]
>
> Owen Anderson wrote:
>> You, as the developer, install/build binutils in MinGW.
>> Then you pull the executables out and stick them in the
>> package that you give your clients.  Thus the clients
>> don't need MinGW.
>
> Interesting suggestion, how confident are you that that will
> be successful?  I have doubts that the binutils in MinGW can
> be executed and used successfully without the rest of MinGW
> being present.  I wonder if your suggestion amounts to
> starting a "Micro-MinGW" fork of MinGW, similar to how MinGW
> started as a fork of Cygwin.


No, it's not nearly that hard.  If it weren't for all the arcane build  
configurations etc., the suggested approach (of extracting the  
assembler and linker) would take just an hour or so.  Even so (with  
the complex build structure), I doubt a competent practitioner would  
need more than a week to get this rolling.

> Also there are possibly licensing problems -- it is worth
> noting that LLVM and MinGW are under different (and possibly
> incompatible) licenses.


I think that because different standalone programs are involved the  
license issues are mostly non-issues.  You'd have to make the source  
for the bits of GNU code you ship available in some way (but not your  
own, which doesn't link against the GNU tools).


> If your suggestion does amount to me starting a
> "Micro-MinGW" fork of MinGW, then I would think my efforts
> would be better directed at helping to finish/implement the
> PEWriter, ELFWriter, MachOWriter in LLVM, and then that work
> would be under the LLVM license.


Well, I'd love to see those things too.  Still, if you want the  
quickest way to a shrink-wrap solution, an approach like the one  
outlined above may be significantly faster (though I really don't know  
what sort of complexities are involved in implementing PEWriter/ 
ELFWriter/MachOWriter).

	Daveed




More information about the llvm-dev mailing list