Re: Question on setting up libraries

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

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.