[LLVMdev] Compiling zlib to static bytecode archive

[Chris Lattner]

On Sep 25, 2007, at 6:12 PM, Maarten ter Huurne wrote:

> On Wednesday 26 September 2007, Chris Lattner wrote:
>
>>> llvm-gcc calling llvm-ld:
>>>   llvm-gcc -> llvm-ld -> gcc -> collect2 -> ld
>>>
>>> enhance collect2:
>>>   llvm-gcc -> llvm-collect2 -> llvm-ld -> gcc -> collect2 -> ld
>>
>> I'd rather enhance collect2 like this:
>>
>> llvm-gcc -> llvm-collect2(liblto) -> ld
>>
>> Where llvm-collect2 is just collect2 that dlopen's liblto to do the
>> optimization work. This makes it work much more naturally than adding
>> a whole new set of steps.  Depending on llvm-ld will never get you to
>> a world where LTO is transparent, because llvm-ld doesn't support a
>> lot of options and features that native linkers do.
>
> So the llvm-collect2 will combine the functionality of the original  
> collect2
> and of llvm-ld?
>
> When it executes, it would take the following steps:
> 1. for each input, determine whether it is in bytecode or native  
> format
> 2. if there are no bytecode inputs, go to step 6
> 3. link the bytecode inputs and optimize the resulting bytecode,  
> using liblto
> 4. if bytecode output was requested, we are done
> 5. generate native object in a temporary file
> 6. perform the init/exit fixups that the original collect2 does
> 7. invoke system linker to link the generated native object (if  
> any) and the
> input native objects (if any)

Yep, exactly.

> Assuming those steps are correct, step 6 and 7 could be implemented  
> by using
> the original collect2 and adding the generated native object to the  
> list of
> files to link. In other words, llvm-collect2 could be a separate  
> process,
> which is called instead of collect2, does some processing and then  
> runs the
> original, unmodified collect2:
>   llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld

Sure, this would also work.  Is there any reason not to merge them  
together?

-Chris