Re: Help! --Interfacing GNAT 3.05 to C libraries

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Geert Bosch wrote:
> 
> Jesus M. Gonzalez (jgb@gsyc.inf.uc3m.es) wrote:
> `` For instance, if you want to compile your ada-program.adb which
>    make a call to Foo, which can be found in libFoo.a library, you
>    can just type:
> 
>         gnatmake ada-program --largs -lFoo ''
> 
> Actually I'd recommend using
>    pragma Linker_Options ("-lFoo");
> 
> in the package using the function. This way you don't need to
> think about all required linker options when using some packages
> in your program. In this case, when "ada-program" uses some package, which
> imports function foo defined in library foo, you only have to
> type the command:
> 
>    gnatmake ada-program
> 
> and your program will be build and the library will be linked in.
> It can't get much easier. (Try this when using C only.)
> 

Please don't! If you then give this program to me, and I try to use
ObjectAda to link it, I have to find and edit the Linker_Options pragma,
based on a weird error message from the linker, which WON'T point me to
the file containing the Linker_Options pragma. (Actually, I don't know
if gnat linker options have the same format as ObjectAda ones, but you
get the point). Linker options are outside the language, and belong in a
makefile, or some other compilation script. This also documents ALL the
components of the system in one place; otherwise, you might forget to
give me libFoo.a. 

( irrelevant aside: This last is a real problem with Visual Basic; the
only way to find out what dlls an app uses is to run it on a minimal
system; it fails at startup with one "missing dll" message. You install
that, and then it asks for another! )

On the other hand, if the Linker_Options pragma is in a system-specific
body, it may indicate that I need to check that body for other changes
when I'm porting; maybe that's a Good Thing.

> Regards,
>    Geert

-- 
- Stephe