[LLVMdev] Compiling zlib to static bytecode archive

[Chris Lattner]

> After studying collect2.c a bit more, I see that quite a lot of it  
> is for
> option parsing and signal handling, so maybe merging is better indeed.

Ok.

> As far as I can see, collect2.c does not read the object files  
> though: it
> only runs "nm" on them, which is not what we need to determine  
> which files
> are bitcode files.

Ok, well you can use the LLVM functions to do this, or just assume  
that if NM doesn't know what it is that it is an LLVM file.  The  
liblto methods should return an error code if the file isn't an llvm  
bc file.

> One thing I'm wondering is how to merge the C code of collect2 with  
> the C++
> code that uses liblto:
> - convert collect2.c to collect2.cpp?
> - put the C++ code in a separate source file and link the C object  
> file and
> the C++ object file together into a single collect2 executable?
> - expose more functionality from include/llvm-c/LinkTimeOptimizer.h?
> (meaning the code using liblto would be C, not be C++)

I'd suggest using the C interfaces as Anton mentioned.

> What does not work yet, is the actual optimization: precollect does  
> not take
> advantage of the fact that this is the final link step that will  
> produce an
> executable and all unreferenced symbols are unused. Therefore the  
> dead code
> elimination from the example is not performed. To make that possible,
> precollect would have to know about all object files, including the  
> native
> ones, to determine which symbols are unused. Also, I should figure  
> out how
> to tell liblto "there are no symbol references that you do not know  
> about";
> I assume that option already exists, but I didn't look for it yet.

If collect2 is already calling nm, you can use the info from nm to  
tell liblto about symbols defined and referenced by the native .o  
files.  This will let transparent mix and match of .o files work.

-Chris