[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