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

[geert@gonzo.sun3.iaf.nl (Geert Bosch)]

Geert Bosch wrote:

   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

Stephen Leake (Stephen.Leake@gsfc.nasa.gov) replied:

   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. 

Geert replies:

It is a bit strange that you make strong claims about weird
error messages you will get because of incompatibility
of pragma Linker_Options between GNAT and ObjectAda, when
at the same time you admit that you don't know about any
incompatibilities.

In any case I do not agree with your comment that Linker_Options
are outside the language. When you look in your Ada RM, you will
find in B.1:

37   Pragma Linker_Options has the effect of passing its string argument as a
parameter to the system linker (if one exists), if the immediately enclosing
compilation unit is included in the partition being linked.  The
interpretation of the string argument, and the way in which the string
arguments from multiple Linker_Options pragmas are combined, is
implementation defined.

This does not sound as outside the language to me, in contrast to
the Makefiles and compilation scripts you suggest as a better
solution.  Of course the standard cannot precisely describe the
effects of pragma Linker_Options (what is a system linker, or
passing a parameter to it?), but I think the intent of the paragraph
is clear.  I would expect all Ada compilation systems to behave
the same on a given platform.

I do not think using pragma Linker_Option is a problem when moving
between platforms. When a package uses an external library or
something else for which a Linker_Option is needed, that package
is system dependent anyway. When moving to another platform changing
Linker_Options might be one of the necessary actions. (It's a good
idea to keep them at the "top" of a compilation unit, just like
platform dependent named constants.)

IMHO makefiles are evil and should be avoided where possible.
Fortunately the Ada language makes it possible to use smart
make tools like gnatmake that do not require "makefiles"
which are complex and hard to maintain because they depend
on all program units.

Now back to the original problem, namely interfacing to a GUI
library. The solution of creating a package that defines the
interface to the the library (using pragma Import and Export) and
has a pragma Linker_Options to link in the GUI library when the
GUI package is withed, is an easy solution that keeps the
system-dependent GUI stuff where it belongs: in the GUI package.

Regards,
  Geert