Help! --Interfacing GNAT 3.05 to C libraries

Help! --Interfacing GNAT 3.05 to C libraries

[Manuel A. Fernandez Fernandez]

I have been trying to use both Ada 95 with C libraries, like 
	Xm from motif, on a Linux box.

	Interfacing to C is simple

	.adb
	procedure Foo;
	pragma Import(C, Foo, "foo");

	.c

	void foo(void){


	gcc -c ada-program.adb ---> ada-program.ali

	gcc -c c-program.c  ------> c-program.o

	gnatbl name.ali name.o

	but how do I link with motif, or whatever?


	what do I have to tell gnat to do that and get my executable?


	thanks in advance.

	Manuel Fernandez.

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

[Jesus M. Gonzalez]

"Manuel A. Fernandez Fernandez" <mfernan@laurel.datsi.fi.upm.es> writes:

	I think you are doing things the hard way. Use gnatmake,
that will make your life a lot easier. 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

	Of course, this assumes that -Foo can be found in the default
library path. For more options of gnatmake, just browse the file
gnatinfo, which you should have got with your Gnat distribution.

	Good luck!!!

		Jesus.

> 
> I have been trying to use both Ada 95 with C libraries, like 
> 	Xm from motif, on a Linux box.
> 
> 	Interfacing to C is simple
> 
> 	.adb
> 	procedure Foo;
> 	pragma Import(C, Foo, "foo");
> 
> 	.c
> 
> 	void foo(void){
> 
> 
> 	gcc -c ada-program.adb ---> ada-program.ali
> 
> 	gcc -c c-program.c  ------> c-program.o
> 
> 	gnatbl name.ali name.o
> 
> 	but how do I link with motif, or whatever?
-- 
Jesus M. Gonzalez Barahona         | addr.:  c/ Butarque, 15
Grupo de Sistemas y Comunicaciones |         28911 Leganes, Spain
Departamento de Informatica        | tel: +34 1 624 94 58
Universidad Carlos III de Madrid   | fax: +34 1 624 94 30
e-mail: jgb@gsyc.inf.uc3m.es       | www: http://www.gsyc.inf.uc3m.es/~jgb

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

[billimad]

>I have been trying to use both Ada 95 with C libraries, like 
>Xm from motif, on a Linux box.

>Interfacing to C is simple but how do I link with motif, or whatever?

First, you'll need to write your own Ada bindings to the X routines
(Xm, Xlib, etc). Alternatively, you can use bindings, such as those
from Intermetrics, already in existance.

GNAT must be able to find the source files for units that are needed by
the unit being compiled. You do this by including command line options
to gnatbl telling the linker the location of these files that it will
require.

-Idir (that's upper case i) appends directory dir to the list of
directories searched for files to include in the linking.

-Ldir appends directory dir to the list of directories to be searched
for -l (that's lower case L) options.

-l (that's lower case L) tells the linker program to use the named
library when linking.

If you use the Intermetrics bindings and these are located in /X11/Ada
and the standard C X11 library is in /usr/X11/lib (for example) then

gcc -c helloworld.adb
gnatbl helloworld.ali -I/X11/Ada -L/usr/X11/lib -lX11
                       ^ upper case i            ^ lower case L

Try the manual entry for gcc, and have a look at
http://ocsystems.com/xada/
(The Free X11/Ada 95 Programmer's Home Page).

Andy

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

[Geert Bosch]

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

Regards,
   Geert

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

[Stephen Leake]

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

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

[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