Re: load and use a ".o" file?

[Stephen Leake <stephen_leake@acm.org>]

lifetime n00b <anonymous@yahoo.com> writes:

> Stephen Leake wrote:
> > .dll and .so files are designed to do _precisely_ what you are trying
> > to do; they are the most efficient solution!
> 
> Well, not _precisely_, since a typical program using the .dll or .so
> files needs to know about those files when it is compiled itself,
> right? 

That's one way to use dynamically linked libraries. But if you look
under the hood, you will see that is just a variant of what you are
doing.

When a program that uses dlls starts up, it dynamically links the dll.
What you want is a program that dynamically links a dll at some later
time. In either case, the dynamic linking is the key.

> Maybe I wasn't clear on exactly what I need to do. The program that
> needs to load and use the object file is *already running* before
> the object file is compiled. This "main program" has no prior
> information about the data or routines which may be in the object
> file it is being told to load.

Well, it can't have absolutely _no_ information. It has to know the
list of subroutines (and their parameter profiles) that are in the
dll. Or, in COM style, it has to have a way of finding out what
subroutines are in the dll; which means it has to know the names of
the introspection subroutines in the dll.

When you dynamically link the compiled file into the main program, you
look up the addresses of those known routines.

> The "main program" operates much like a command prompt, and when
> (compile-file "hithere") is typed at the prompt, gnat will be called
> to compile an object file. Then when (load "hithere") is typed at
> the prompt, the object file is loaded and the data and/or functions
> in "hithere" are now available to the main program. 

Yes, that is what I thought you were doing. But how does the main
program know the names of the functions in "hithere"?

> Some additional information may have to be included in a supporting
> file produced at the same time the object file is produced, and this
> supporting file would be loaded when the object file is loaded.

Ah; perhaps that's the names of the functions? In Windows, that's a
.def file, which lists the names of the functions in a dll.

> That's the idea anyway. But I'm having a difficult time trying to
> figure out how to accomplish this seemingly straightforward task.

Go read the manuals on dlls, and dynamic linking in general, and on
COM. You are re-inventing the wheel! It may seem straightforward, but
it gets quite complicated. Fortunately, it has been solved.

Most good ideas have been thought of before :).

-- 
-- Stephe