Re: Any Compilation Gurus?

[bob@xxxxxxx]

Adam Williams <awilliam@whitemice.HN.org> Wrote:
>So I revise my question:  What is libtool?
libtool is actually this big script that provides a layer of abstraction
for utilities that build libraries. Some of these tools vary from system
to system, and there are different implementations (and syntax rules) for
the library creation, especially dynamicly loaded and/or share libs.
  
>...is there a good intro-document to what all this means?
Sorta:
http://www.gnu.org/software/libtool/manual.html

"intro" and "libtool" are kinda mutually exclusive notions. If you feel 
comfortable using ranlib and ar, and similarly user-freindly utilities,
you're ready for the above. If you don't, or you never heard of these things,
you're probably not. 

>I roughly understand make (make), compile (gcc), and link (ld), but the 
>configure/make scripts of some of these new packages makes my eyes water.
Your eyes might REALLY water if libtool did not exist, since all that stuff
would in essence be coded in-line.

You are missing the 4th leg of building stuff here, and that's how librarieds 
get built....

If you want to build a static library, you use ar (on every UNIX type system 
I've ever stumbled across) to create an ARchive [see?] of object files, each of 
which can be fetched out individually. to speed lookups at link (ld) time,
ranlib creates a table of contents (or TOC); we can think of it as an index,
or a listing of entry points and locations in each file for each routine 
that was identified by the compiler as something that the programmer wanted 
to call externally (from another object module). The linker (ld) then strings 
everything together, going into each libarary (formed by ar, indexed by ranlib)
and fetching out library routines. An executable so formed is said to be 
linked staticly. This sort of executable will run all by itself (at least in 
the context of the the correct OS), without need for libraries at run time.
Since ALL the code is included in a static executable, it's bound to be fairly
large.

Dynamically linked libraries are NOT linked at compile time, but the
linker (NOT ld, but ld.so or ld-linux.so, for example) instead checks that
the libraries are available, and what routines (by name, not address!) are
in each library. A small (compared to all that static code) lookup and reading
routine is embedded in the executable, and the executable formed is ready to 
run, but the libraries must be present at run time. This means that the 
executable can be a lot smaller, and the libraries can change without 
requiring all the executables to be recompiled and linked. One could argue 
that there is a performance penalty for loading up library routines at run
time, but for a great many practical things it is not noticeable, and worth
the extra flexibility granted by smaller size and a modular design. 

I've simplified the above some for the sake of brevity, and perhaps I ought to 
make mention of the fact that you can use ar for other things, even if it's 
rare. I'll leave the details of things like ldd, ld.so, and ld-linux.so to the 
reader, who may be motivated by curiousity and a need to build shared 
libraries, or read the libtool script and enjoy.....

                                                            Regards,
                                                             ---> RGB <---