[LLVMdev] Libraries? What Libraries?

[Chris Lattner]

On Mon, 2 Feb 2004, Reid Spencer wrote:

> I'm trying to figure out which LLVM libraries (er.. object files that
> is) I should link with my programs. It isn't clear to me what the build
> output of LLVM is.  I tried the new make "install" target and got a
> plethora of .o files. The few .a files I got had _likely_to_conflict_
> names such as "libsupport.a" and "libtarget.a".  None of the .o files
> are shared objects, they're just regular relocatable object files.

> Is there some aversion to using shared objects?

Hrm, interesting question that.  You can currently build shared libraries
easily by setting SHARED_LIBRARY=1 in the makefile for a library.
Originally, all of the LLVM libraries were built as shared objects, which
made it so you didn't have to relink tools when a library internal change
was made (this was nice).

However, startup time of the applications were _incredibly_ slow when
everything was built into shared objects, comperable to the time required
to link the application to static libraries in the first place.  Since
this was the case, we switched over.

> Is there some documentation on what is in each of these .o and .a files?

Uhh... not really.  The general rules is that "atomic" libraries such as
lib/Target/X86 are built into .o files, as they are always used together.
Libraries that can have some portion of the library used, but not others,
are linked as .a files (e.g., lib/Transforms/Scalar, the idea being that
you need only link the transformations used by a tool into it, not the
whole library).

To make things more complex, we have some tools that want to link in
_every_ transformation/analysis in a directory, without having to know
what they all are (their static ctors register them).  These tools (like
opt, bugpoint, and analyze) thus link to the scalaropts.o file instead of
the libscalaropts.a file, causing _all_ transformations to be linked in.

There isn't any good documentation of what each library does, but if you
have specific questions, I can certainly answer them.  The big problem is
the dependencies between the libraries.  For example, lib/Target/Sparc
depends on the scalar optimizations, which is not intuitive.

> P.S. I noticed that "make install" only installed the
> llvm/Config/config.h header file and none of the others. Is this feature
> partially implemented or is there a bug?

I don't know, perhaps Brian can help here.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/