Re: dynamic loading and Ada95

[Louis-Dominique Dubeau <ldd@step.polymtl.ca>]

stt@houdini.camb.inmet.com (Tucker Taft) writes:

> Louis-Dominique Dubeau (ldd@step.polymtl.ca) wrote:
> 
> : I'm looking for implementations of dynamic loading for Ada95.  I made
> : an implementation of dynamic loading for Modula-3 and wish to compare.
> 
> The AppletMagic(TM) Ada95 => Java byte code compiler uses
> dynamic loading.

What implementation of Ada95 was used to build AppletMagic?

> : The problematic in both cases should be similar in at least two points:
> 
> : - how to integrate package information after a dynamic load
> 
> Java has the notion of "class initialization" routines.  These
> are executed after a class is loaded.  In our mapping, a package
> spec and a package body each turn into a Java class, each with
> its own class-init routine.  These are executed when the package
> is loaded.

You're outside the scope of my question.  I want to know if a core
program written in Ada95 is able to load a shared objet written in
Ada95 and then use it or if it will break.

This is implementation dependent.  I believe in GNAT you'd have a
problem.  Here is how a GNAT compiled program starts:

- main is called
- it calls the elaboration routines of bodies and specs.
- then calls the main function/procedure of the program

The elaboration routines are responsible to build type information for
the types they implement.  If you use dlopen() (for the ELF case) and
dlsym() to load a package and get the entry point to a function that
uses a type defined in that package, you're going to see fireworks.
The elaboration procedure of the package was never called (libdl
doesn't know about Ada) and thus the type doesn't exist.

The fix would be to have an Ada library do the work of loading the
package and then ensuring that the elaboration procedure is called,
etc.

	Regards,
	ldd