Re: Question on setting up libraries

Re: Question on setting up libraries

[Ludovic Brenta]

randomm@mindless.com writes:
> I was working through the ncurses installation and I would
> appreciate recommendations on setting up libraries.

Please look at the Debian Policy for Ada [1] or the GNU Ada
Environment Specification [2]; they discuss this.

[1] http://www.ada-france.org/debian/debian-ada-policy.html
[2] http://cert.uni-stuttgart.de/projects/ada/gnae.php

You can apply this knowledge on other (non-unix-like) systems, too, to
decide on your own policy.

-- 
Ludovic Brenta.

Re: Question on setting up libraries

[Jeffrey R. Carter]

randomm@mindless.com wrote:
> 
> What is the proper way to manage all this?  Presently I've got:
> 
> libAdaCurses.a
> *.o
> *.ali files
> in a directory in my ADA_OBJECTS_PATH
> 
> and
> *.adb
> *.ads
> in a directory in my ADA_INCLUDE_PATH

This is clearly GNAT specific. For GNAT, I tend to put the sources, .o, 
and .ali files together in one directory, mentioned in both paths. That 
also seems to be the way that GtkAda and JEWL handle things.

> Is this the proper way to group things together?  Please tell me the
> proper way to handle this scenario.

There is no "proper" way; you can do whatever seems best for you 
(provided it works, of course).

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: Question on setting up libraries

[Simon Wright]

randomm@mindless.com writes:

> What is the proper way to manage all this?  Presently I've got:
>
> libAdaCurses.a
> *.o
> *.ali files
> in a directory in my ADA_OBJECTS_PATH
>
> and
> *.adb
> *.ads
> in a directory in my ADA_INCLUDE_PATH

I don't personally bother with precompiling libraries, I just put the
source in the Ada source path (using GNAT Project, or -I if it's a
quick hack) but I can see that some people don't like that.

With that said, your scheme seems OK except I'd have expected _either_
the .o's _or_ the .a; looking at the installation here the Ada library
has

   $ ls /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/*.[ao]
   /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/g-trasym.o
   /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgccprefix.a
   /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgmem.a
   /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgnarl.a
   /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgnat.a

so there the choice isn't 100% for some deep reason; but the compiler
will have special magic to include the necessary linker directives for
itself.

I'd expect the equivalent in your case to be in a GNAT Project file
for AdaCurses (adacurses.gpr??); or perhaps in a pragam Linker_Options
somewhere.

Re: Question on setting up libraries

[Ludovic Brenta]

Simon Wright <simon@pushface.org> writes:
>    $ ls /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/*.[ao]
>    /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/g-trasym.o
>    /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgccprefix.a
>    /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgmem.a
>    /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgnarl.a
>    /opt/gnat-gpl-2005/lib/gcc/powerpc-apple-darwin7.4.1/3.4.5/adalib/libgnat.a
>
> so there the choice isn't 100% for some deep reason; but the compiler
> will have special magic to include the necessary linker directives for
> itself.

g-trasym.o contains GNAT.Traceback.Symbolic_Tracebacks.  It relies on
an external program (addr2line) or library (libaddr2line.a) to
translate addresses to line numbers in the source code.  If you bind
with gnatbind -E and use symbolic tracebacks, you need this object
file and the program or library.  If you don't need symbolic
tracebacks, then libgnat.a and libgarl.a are sufficient.

Some parts of libgnat.a need libgccprefix.a, too (see gnatvsn.ads,
gnatvsn.adb).

On Debian, both g-trasym.o and libgccprefix.a are packaged into
libgnat.a for simplicity.  addr2line is always available, because it
is part of binutils, which are necesary anyway to produce any object
file (binutils contains as and ld).

> I'd expect the equivalent in your case to be in a GNAT Project file
> for AdaCurses (adacurses.gpr??); or perhaps in a pragam
> Linker_Options somewhere.

Yes.

-- 
Ludovic Brenta.

Re: Question on setting up libraries

[Martin Krischik]

randomm@mindless.com wrote:

> X-No-Archive: Yes
> 
> Hello all,
> 
> I was working through the ncurses installation and I would appreciate
> recommendations on setting up libraries.

You might want to have a look on how charles is packaged up for the GNU Ada
Project:

http://svn.sourceforge.net/viewcvs.cgi/gnuada/trunk/rpm/SPECS/Prototypes/gnat-charles.spec?view=markup&rev=273

search for %install

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Question on setting up libraries

[Ludovic Brenta]

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.

Re: Question on setting up libraries

[Ludovic Brenta]

randomm@mindless.com writes:
> Actually my preference is generally to tolerate a larger executable
> in order to make packaging simpler and reduce external dependencies
> for the user.  So your first explanation about the .a seems to be
> most helpful.  I understand the tradeoff, but I prefer to be able to
> guarantee my environment to the extent possible rather than to bet
> on the questionable valuable of new library versions, at least this
> is how I did it "back in the old country."

That's fine for a one-off program, but not if you want to provide a
complete platform or suite of programs.  YYMV.

[...]

> so in my trivial test scenario it seems that I need the .o files.  I
> haven't had time to go through all the materials you and the other
> people have suggested so perhaps this is all explained therein.
>
> I haven't proven it but it certainly looks as though the libAdaCurses.a
> contains all the necessary object files so I should find out how to use
> those and then I can remove all the .o files from adalib.

Yes.  See below.

>> 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.
>
> That sounds like a much better idea.  I hope I'll be able to
> utilitize these properly shortly.

To link statically, if libAdaCurses.a is in the current directory:

gnatmake first -g -cargs -gnatfloqv -O -largs libAdaCurses.a

To link dynamically, if you have libAdaCurses.so in /usr/lib:

gnatmake first -g -cargs -gnatfloqv -O -largs -lAdaCurses

> I should note that the libAdaCurses.a was also not copied by the
> make install.  So it still seems a problem.

Yes, that's a second bug in the installation of AdaCurses.

-- 
Ludovic Brenta.

Re: Question on setting up libraries

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> 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.

Also .dylib on Mac OS X. But there are .so's too ..