[gambit-list] gambit + llvm

Christian Jaeger christian at pflanze.mine.nu
Mon Sep 22 14:59:16 EDT 2008


Alex Sandro Queiroz e Silva wrote:
> Hallo,
>
> Christian Jaeger wrote:
>   
>> Alex Sandro Queiroz e Silva wrote:
>>     
>>>      The code generator of LLVM is deployed as a library. It's a very
>>> different thing to deploy a library (linked statically or as shared
>>> objecyts) and deploying a complete development environment.
>>>   
>>>       
>> In which way is it different? In every Linux system it would just be a
>> dependency on a package, the rest is solved. In Windows or OS X it would
>> probably a question of statically linking the libraries or bundling the
>> libraries or binaries with your package. Why is bunding a binary more of
>> a problem than bundling a library? (And you might have other binaries
>> you'd want to bundle with your package anyway!)
>>
>>     
>
>      I can't believe you are serious. It is just not bundling a binary.
> It is bundling a compiler, a linker, an assembler, header files (ANSI C
> and OS-specific), libc, linker scripts etc. Can't you see this is
> different than shipping just a library to a client?
>
>   
>> It's a question of balance. Developing an llvm backend just because
>> there is no nice script bundling up all your dependencies into one
>> deployable blob would be energy invested in the wrong place.
>>
>>     
>
>      I never asked for a LLVM backend for Gambit-C. I only replied (and
> now I regret that) because someone said it would be no different at all
> of the current system. And it would.
>   

I really didn't mean to attack you, I simply want to know of solid 
reasons for creating an LLVM backend.

I'm an almost 100% linux users for 9 years now (and I have only had the 
issue of delivering a package to windows users once, which was a program 
in Visual Basic and actually required bundling of all DLL's to be 
running stable).

So I can't talk for anyone on such a system on what is required. I was 
replying on the assumption that by using PATH, LD_LIBRARY_PATH (or the 
Windows equivalents) and the gcc -I and -L options you can move all 
dependency files around at will, so what difficulty remains would be to 
find the dependencies (on Linux you could do it by using strace, or by 
including just the whole toolchain), so I guess it will be the size of 
the resulting package which makes you question my seriousness. I'm sure 
it would be worthwhile hearing about numbers or experience in this area.

If you need to package libc, then why wouldn't you need to package it 
also when using LLVM? (My reasoning being: if libc's interfaces (aka 
header files) are compatible with the header files you're providing, you 
don't need to include the libc binary, and if it isn't compatible with 
what assumptions the packaged-up system has (even if it's based on 
LLVM), then you'd need to include it anyway.)

Christian.




More information about the Gambit-list mailing list