[LLVMdev] ObjectFiles.html

Reid Spencer reid at x10sys.com
Fri Feb 27 08:24:01 PST 2004


On Thu, 2004-02-26 at 22:41, Chris Lattner wrote:
> On Fri, 27 Feb 2004, Chris Lattner wrote:
> > > Could someone please add this file to the LLVM docs directory so I can
> > > submit patches against it?
> 
> BTW, here's some hints for it:

Thanks Chris, I'll add them.

> Basically, libraries are built in two forms: .a files and .o files.  .o
> files are built/used when client programs want to link in _everything_ in
> a library.  .a files are used when a client program wants to use some of
> the stuff in a library, based on what symbols are referenced.
> 
> The difference is important for things like 'opt' which wants to link in
> _ALL_ optimizations no matter what, and 'gccas' which only wants to link
> optimizations in that are referenced by the gccas tool explictly.
> 
> For libraries that .a files don't make sense, we don't provide them.  It's
> impossible to link in half an x86 backend for example.  :)

While I understand the motivations you describe above, something about
this bothers me.  As a tool provider the LLVM developers are trying to
provide small/fast/quick linking tools. The above approach helps with
some of that.  However, I'm an LLVM user and a big part of using LLVM is
linking my code with LLVM code. When the LLVM developers opt to make a
.o "library", they're essentially forcing users to take all or nothing.
As you mentioned in the case of x86 backend, this may make a lot of
sense. On the other hand, it presumes the developers of LLVM know how
the users want to use LLVM!  Say there's a little utility function in
the x86 backend that I want to use but I'm not generating any x86 code?

> 
> 
> Overall, this looks really useful, especially when the dependency
> information is built.  Perhaps this should eventually be integrated into
> the programmers manual though?

Perhaps, but with hypertext, what does "integrated" really mean? :)
> 
> -Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040227/d6a11be3/attachment.sig>


More information about the llvm-dev mailing list