Re: Question on setting up libraries

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

randomm@mindless.com writes:
> Wow what a tremendous response!  Thanks loads to everyone!  I've
> bookmarked this thread and I'll go through all of your suggestions.
>
> Do I understand correctly that the libAdaCurses.a is a run-time type of
> library designed to provide dynamic service to an executable that was
> bound without including the services in libAdaCurses.a?   Then how do I
> tell gnatmake that I want to either have a module that I write
> completely self-contained or not to include what's in libAdaCurses.a so
> that it will branch to it at execution time?

No.  By convention, files ending with ".a" (for "archive") are static
libraries.  The linker ("ld") copies part of that archive into your
program.  Then, your program can the run even if the library isn't
there anymore.

In contrast, shared libraries have, by convention, the extension .so
(for "shared object") on GNU/Linux and most other systems, or .sl
("shared library") on HP/UX.  But there is more to it; most often the
.so or .sl files are really symbolic links to the actual shared
library.  You need to know about the "soname" to really understand
why.  Have a look here:

http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Windows or OS/2 have "dynamic link libraries" (*.dll) which are
roughly equivalent to shared libraries, except they don't have an
soname, leading to "DLL hell".

If you link dynamically against a shared library, then your program
does *not* contain the corresponding object files; it only contains
stubs, generated by the linker, which load the shared library and call
the subprograms in it.  So, the executable file is smaller, and you
can replace the shared library with a new version without recompiling
or relinking your program.  But your program *requires* the presence
of a shared library with the right "soname".

I believe that that's what you want.

> Just a note for anyone who is thinking about using ncurses with Ada,
> I think there are some minor but very troublesome problems with the
> installation of the 5.5 version.  terminal_interface.ads doesn't get
> copied to the adainclude library (causing compilation errors) and
> neither do *any* of the .o modules.

That's the right thing to do.  The object files are actually members
of the .a "archive".  You can try:

$ ar tf libAdaCurses.a

If GNAT sees object files (.o), it copies them into the final
executable, no matter what.  In the case of static linking, it does
not make a difference, but makes dynamic linking problematic.

That's why, for example, the Debian Policy for Ada *forbids* library
packages from supplying .o files at all.  They must supply the .a
static library and the .so shared library instead.

> My problems of not knowing enough even what to ask for are
> complicated by broken installations!

:-)

-- 
Ludovic Brenta.