Linking an ADA routine to a program written in C

Linking an ADA routine to a program written in C

[newmans]

I desperately need an explanation of how to link a routine written and compiled in ADA into a program
written in C.  For example, I built an ada  test procedure hello.a and compiled it using the ada compiler.
The object file produced was called hello01.  This program uses TEST_IO package to do the output.

Since the object module hello01 is ELF-32 bit I linked it in with my C objects using gcc.  But of course,
I get undefined symbols because I have no idea how to tell gcc about the TEST_IO package.  

Does anyone know how this can be done.  

Also, some people have mentioned that I may have to use a PRAGMA in my C code to tell the
compiler that the  routine I am calling  i.e. "hello"  is not a C subroutine.  C passes arguments from
right to left.  I believe ADA probably passes them like PASCAL from left to right.  In C you can declare
a routine to be type pascal to change the calling sequence to match PASCAL's.  If anyone has
any experience calling ADA routines from C please contact me ASAP. 

		Thank you! 

Re: Linking an ADA routine to a program written in C

[Larry Kilgallen]

Given the fact that you mention gcc, I suppose we might guess that
your Ada compiler is GNAT.

I just can't figure out how we will guess what type of computer you
are using.  Based on your comments about right-to-left and left-to-right,
I would tend to say Macintosh, but I know a reasonable amount about
Macintosh and have never heard the term "ELF-32".

Try writing a problem report like you were the person reading it.
Those Ada people are sticklers for clarity.

Larry Kilgallen

In article <51p2vu$enf@lal.interserv.com>, newmans@ncr.disa.mil writes:
> 
> I desperately need an explanation of how to link a routine written and compiled in ADA into a program
> written in C.  For example, I built an ada  test procedure hello.a and compiled it using the ada compiler.
> The object file produced was called hello01.  This program uses TEST_IO package to do the output.
> 
> Since the object module hello01 is ELF-32 bit I linked it in with my C objects using gcc.  But of course,
> I get undefined symbols because I have no idea how to tell gcc about the TEST_IO package.  
> 
> Does anyone know how this can be done.  
> 
> Also, some people have mentioned that I may have to use a PRAGMA in my C code to tell the
> compiler that the  routine I am calling  i.e. "hello"  is not a C subroutine.  C passes arguments from
> right to left.  I believe ADA probably passes them like PASCAL from left to right.  In C you can declare
> a routine to be type pascal to change the calling sequence to match PASCAL's.  If anyone has
> any experience calling ADA routines from C please contact me ASAP. 
> 
> 		Thank you! 

Re: Linking an ADA routine to a program written in C

[David C. Hoos, Sr.]

newmans@ncr.disa.mil wrote in article <51p2vu$enf@lal.interserv.com>...
> 
> I desperately need an explanation of how to link a routine written and
compiled in ADA into a program
> written in C.  For example, I built an ada  test procedure hello.a and
compiled it using the ada compiler.
> The object file produced was called hello01.  This program uses TEST_IO
package to do the output.
> 
> Since the object module hello01 is ELF-32 bit I linked it in with my C
objects using gcc.  But of course,
> I get undefined symbols because I have no idea how to tell gcc about the
TEST_IO package.  
> 
> Does anyone know how this can be done.  
> 
> Also, some people have mentioned that I may have to use a PRAGMA in my C
code to tell the
> compiler that the  routine I am calling  i.e. "hello"  is not a C
subroutine.  C passes arguments from
> right to left.  I believe ADA probably passes them like PASCAL from left
to right.  In C you can declare
> a routine to be type pascal to change the calling sequence to match
PASCAL's.  If anyone has
> any experience calling ADA routines from C please contact me ASAP. 
> 
> 		Thank you! 
>
This is an implementation-dependent thing.  Generally what has to be done
is to tell the Ada compiler that the routine is to be called by a C
compilation unit.  This is done with a pragma such a EXPORT or EXTERNAL,
depending on the implementation.  Consult your compiler documentation,
looking especially for discussions of Interface Programming.

Further, the issue of "withed" packages pretty much requires that your main
program be an Ada program.  If you already have a suitable "main" program
written in C, you would need to put an Ada "wrapper" around the C main. 
The C main might have to be renamed, depending on the Ada implementation,
because some Ada systems use a routine called "main", which would confuse
the linker of there were two "main" symbols declared.

The Ada main program also allows the elaboration code for each compilation
unit to be called before the main program begins execution.

The only kind of Ada unit which can be called from C is one in which there
is NO elaboration code in the unit, or in any of the other Ada units it
"withs".

Hope these ramblings are helpful.
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com


 

Re: Linking an ADA routine to a program written in C

[Larry Kilgallen]

In article <01bba5e0$cf06b040$328371a5@dhoossr.iquest.com>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> This is an implementation-dependent thing.  Generally what has to be done
> is to tell the Ada compiler that the routine is to be called by a C
> compilation unit.  This is done with a pragma such a EXPORT or EXTERNAL,
> depending on the implementation.  Consult your compiler documentation,
> looking especially for discussions of Interface Programming.
> 
> Further, the issue of "withed" packages pretty much requires that your main
> program be an Ada program.  If you already have a suitable "main" program
> written in C, you would need to put an Ada "wrapper" around the C main. 
> The C main might have to be renamed, depending on the Ada implementation,
> because some Ada systems use a routine called "main", which would confuse
> the linker of there were two "main" symbols declared.
> 
> The Ada main program also allows the elaboration code for each compilation
> unit to be called before the main program begins execution.
> 
> The only kind of Ada unit which can be called from C is one in which there
> is NO elaboration code in the unit, or in any of the other Ada units it
> "withs".

Although the restrictions listed may be overly broad.  Although I
don't really use C, I do use shareable libraries with DEC Ada on
VMS (both platforms), and from what I understand of the mechanism
using C, even as the main program, should not be a barrier to
elaboration.  Perhaps I have just been lucky, but with 160,000 lines
of code, I have never had to worry about "elaboration", it "just
happens".  It uses the LIB$INITIALIZE mechanism, which would surely
not be inhibited by intermixing C.

Larry Kilgallen

Re: Linking an ADA routine to a program written in C

[Chris Brand]

Calius wrote:
> [snip]
> 
> I'm sorry to "barge" into your thread here :), but I can tell you this:
> I've called ADA procedures which require elaboration from C several
> times. I know
> it works, and as Larry, it "just happens".  I can, however, explain WHY
> is "just
> happens" (Or so I think):
> 
> [more snipping]

I've used ada code with a C main program and with at least one compiler (DEC compiler on an
Alpha, I think), you had to call an elaboration routine before calling any ada. You also
had to call a "finalisation" routine when you'd finished calling ada.
There is usually some sort of compiler option to tell it to create an object file rather
than an executable, and it should include all the necessary ada code (including "with"ed
library packages) if you do this.
As has already been mentioned, you need to tell the ada code that your subprogram will be
called from C, and possibly what it should be known as to the linker.
You then just use your C compiler as usual and include your ada object file in the link.

-- 
Chris
Stating my own opinions, not those of my company.

Re: Linking an ADA routine to a program written in C

[Calius]

>
> snip nip
>
> Perhaps I have just been lucky, but with 160,000 lines
> of code, I have never had to worry about "elaboration", it "just
> happens".  It uses the LIB$INITIALIZE mechanism, which would surely
> not be inhibited by intermixing C.
> 
> Larry Kilgallen

I'm sorry to "barge" into your thread here :), but I can tell you this:
I've called ADA procedures which require elaboration from C several
times. I know
it works, and as Larry, it "just happens".  I can, however, explain WHY
is "just
happens" (Or so I think):

My implementation of ADA ( Verdix SELF ) has a pragma ELABORATE, which
tells the
runtime system that each time a procedure is called, the entry code for
that procedure should check to make sure that the procedure was
elaborated, and if not,
elaborate at runtime.  That's all there is to it.

                                                    Calius

Re: Linking an ADA routine to a program written in C

[Cyrille Comar]

>>>>> "David" == David C Hoos, <david.c.hoos.sr@ada95.com> writes:
In article <01bba5e0$cf06b040$328371a5@dhoossr.iquest.com> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

    David> This is an implementation-dependent thing.  Generally what
    David> has to be done is to tell the Ada compiler that the routine
    David> is to be called by a C compilation unit.  This is done with
    David> a pragma such a EXPORT or EXTERNAL, depending on the
    David> implementation.  Consult your compiler documentation,
    David> looking especially for discussions of Interface
    David> Programming.
    David> Further, the issue of "withed" packages pretty much
    David> requires that your main program be an Ada program.  If you
    David> already have a suitable "main" program written in C, you
    David> would need to put an Ada "wrapper" around the C main.  The
    David> C main might have to be renamed, depending on the Ada
    David> implementation, because some Ada systems use a routine
    David> called "main", which would confuse the linker of there were
    David> two "main" symbols declared.


Sorry to jump in a bit late on this thread but I just wanted to add
that all the above description is perfectly correct for Ada83 but is
far from the reality of Ada (Ada 95). Interfacing with most other
languages is not implementation-defined anymore. This is perfectly
well defined in the R.M. See description of pragma Import/Export and
definition of standard procedures adainit (for elaboration of the Ada
part when main is not in Ada) and adafinal (for finalization of the
same Ada part). All of this is completely standard and implemented as
required at least in GNAT but most probably in other Ada95 compilers
as well.

Cyrille


 

Re: Linking an ADA routine to a program written in C

[Larry Kilgallen]

In article <COMAR.96Sep24165621@dantes.enst.fr>, comar@dantes.enst.fr (Cyrille Comar) writes:

> Sorry to jump in a bit late on this thread but I just wanted to add
> that all the above description is perfectly correct for Ada83 but is
> far from the reality of Ada (Ada 95). Interfacing with most other
> languages is not implementation-defined anymore.

I seem to recall about 5 languages being listed in the standard,
which hardly clarifies as "most", especially since it leaves out
some of my favorites :-).

The ability of an implementor to support linkage to additional
languages does not give one the ability to count on that support
from another vendor.

Larry Kilgallen

Re: Linking an ADA routine to a program written in C

[Jens Jakob Jensen]

In article <COMAR.96Sep24165621@dantes.enst.fr>,
comar@dantes.enst.fr (Cyrille Comar) wrote:
[snip]
>(Ada 95). Interfacing with most other
>languages is not implementation-defined anymore. This is perfectly
>well defined in the R.M. See description of pragma Import/Export and
>definition of standard procedures adainit (for elaboration of the Ada
>part when main is not in Ada) and adafinal (for finalization of the
>same Ada part). All of this is completely standard and implemented as
>required at least in GNAT but most probably in other Ada95 compilers
>as well.
>
>Cyrille

I haven't followed this thread, so I'm sorry if it's off-topic. But I have
long been wondering what the consensus is wrt. finalization and things like
signals, OS-exceptions, C abort() &c.

Should the Runtime go out of its way to finalize things, or should the
programmer write signal handlers, OS-exception handlers, and override
abort() &c ?

Since I am using GNAT under OS/2, where finalization isn't done when a signal
is raised (eg. Ctrl-C/SIG_BREAK) I would be interested in what consensus is
and what other compilers do.

Is it at all possible to _ensure_ that finalization gets done when interfacing
with C ? (when not counting power/hardware failures)

Thanks in advance for any info...

-----------------------------------------------------------------------------
--          jjjensen@cybernet.dk   (current)                               --
-- Jens_Jakob_Jensen@mailhost.net  (permanent, thanks to www.pobox.org.sg) --
-----------------------------------------------------------------------------

Re: Linking an ADA routine to a program written in C

[Robert Dewar]

Larry said

"I seem to recall about 5 languages being listed in the standard,
which hardly clarifies as "most", especially since it leaves out
some of my favorites :-)."

Actually only 3 languages are mentioned epxlicitly, and the claim should
have said "interface with most other standardized languages". Obviously
the ISO standard for Ada 95 cannot talk about nonstandardized languages
like C++ Java, or whatever.,

However, in practice, since Ada 95 can duplicate a C interface, Ada 95
can certainly interfac to anything that C (or for that matter Fortran
or COBOL) can interface to. Of course, as is generally true for interacing
from C to anything, such interfaces may indeed be non-portable.

Re: Linking an ADA routine to a program written in C

[Larry Kilgallen]

In article <dewar.843920011@schonberg>, dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:

> However, in practice, since Ada 95 can duplicate a C interface, Ada 95
> can certainly interfac to anything that C (or for that matter Fortran
> or COBOL) can interface to. Of course, as is generally true for interacing
> from C to anything, such interfaces may indeed be non-portable.

As far as _non-portable_ interfaces to other languages, I can do that
with an Ada 83 program, since I can generally figure out how to program
in assembly language, and in my experience understanding the underlying
machine calling sequences is essential for figuring such things out even
if the linkage is to be constructed in a compiled language.

So the great promise of Ada95 is not interfacing to other language
but _portable_ interfacing to other languages.  Luckily the main code
to which I must portably interface is written in C.

Larry Kilgallen

Re: Linking an ADA routine to a program written in C

[Robert Dewar]

Larry says

"> However, in practice, since Ada 95 can duplicate a C interface, Ada 95
> can certainly interfac to anything that C (or for that matter Fortran
> or COBOL) can interface to. Of course, as is generally true for interacing
> from C to anything, such interfaces may indeed be non-portable.

As far as _non-portable_ interfaces to other languages, I can do that
with an Ada 83 program, since I can generally figure out how to program
in assembly language, and in my experience understanding the underlying
machine calling sequences is essential for figuring such things out even
if the linkage is to be constructed in a compiled language.
"



This shows that you do not have muych experience in the use of Ada 95 in
constructing such interfaces, since what you say is simply wrong for
Ada 95, you can interface GNAT to a wide range of languages by following
whatever C would do without having the slightest idea of what the
underlying machine calling sequence is.

Perhaps your experience with Ada 83 is indeed typical, perhaps it is
not, but in any case it seems irrelevant with respect to Ada 95.

Re: Linking an ADA routine to a program written in C

[Larry Kilgallen]

In article <dewar.844372753@schonberg>, dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
> Larry says
> 
> "> However, in practice, since Ada 95 can duplicate a C interface, Ada 95
>> can certainly interfac to anything that C (or for that matter Fortran
>> or COBOL) can interface to. Of course, as is generally true for interacing
>> from C to anything, such interfaces may indeed be non-portable.
> 
> As far as _non-portable_ interfaces to other languages, I can do that
> with an Ada 83 program, since I can generally figure out how to program
> in assembly language, and in my experience understanding the underlying
> machine calling sequences is essential for figuring such things out even
> if the linkage is to be constructed in a compiled language.
> "

> This shows that you do not have muych experience in the use of Ada 95 in
> constructing such interfaces, since what you say is simply wrong for
> Ada 95, you can interface GNAT to a wide range of languages by following
> whatever C would do without having the slightest idea of what the
> underlying machine calling sequence is.

And how do I find out "whatever C would do" ?

Are you presuming that every Ada programmer is a former C programmer ?

The little bit of C I do know does not seem to support that
portability argument.  VMS C programmers call to Pascal routines
without specifying that the language being called is Pascal.
When they port that C code to 68K Macintosh, they must add
a keyword to their source to indicate that the language being
called is Pascal.  Presumably any Ada implementation must deal
with that issue as well, but adding a keyword on getting to a
new platform is not what I would call portable.

Or even consider calling out to C programs.  I buy object
code which was written in C from one vendor.  If I were to
buy different object code from another vendor who happened
to use a different brand of 68K Macintosh C compiler (there
are 4 available at last count), I would have to specify in
my Ada program which brand of C was used for the various
imported C subroutines, since there are different binary
calling conventions for the various brands of C compiler.
This is not an issue on VMS (unless gcc has managed to
avoid using the common calling standard), so the Ada code
I had written on VMS would need to be "augmented" in order
to work on 68K Macintosh.

Now admittedly, I only have one current vendor from whom
I get multi-platform subroutines written in C.  I am sure
there are other vendors selling software in that format,
but it is unlikely their subroutines are something I want.

> Perhaps your experience with Ada 83 is indeed typical, perhaps it is
> not, but in any case it seems irrelevant with respect to Ada 95.

Presentation of such a broad marketing claim seems intended to win me
over on our previous discussions regard GNAT being "commercial" :-)

Larry

Re: Linking an ADA routine to a program written in C

[Robert Dewar]

Larry said

  The little bit of C I do know does not seem to support that
  portability argument.  VMS C programmers call to Pascal routines
  without specifying that the language being called is Pascal.

This is in response to my "argument"

  This shows that you do not have muych experience in the use of Ada 95 in
  constructing such interfaces, since what you say is simply wrong for
  Ada 95, you can interface GNAT to a wide range of languages by following
  whatever C would do without having the slightest idea of what the
  underlying machine calling sequence is.

This was not intended at all as a "portability argument", but rather was
a response to Larry saying:

  As far as _non-portable_ interfaces to other languages, I can do that
  with an Ada 83 program, since I can generally figure out how to program
  in assembly language, and in my experience understanding the underlying
  machine calling sequences is essential for figuring such things out even
  if the linkage is to be constructed in a compiled language.

My point was that in the realm of non-portable interfaces to other languages,
e.g. how do I interface to smalltalk? you do not need to rummage about at
the assembly language level!