Mark Morgan Lloyd wrote:
>> Can such an alternative entry point in the main unit be called by
>> a shared library, i.e. either resolved at load time or with the main
>> binary reopened like a library? Or is the only way to pass a main-
>> program entry point to a shared library by using it as a parameter
>> to a procedure?
> I can't tell you for *nix systems as I'm not experienced enough
> regarding their dynamic linkers,
Superficial testing suggests that if the code in a .so (Linux, i386)
tries to call an "extra" entry point exported from the main program,
that a run-time (libdl) load of the library will fail. I'll keep on
tinkering with this, I've not yet retrieved the exact error message and
I'm interested in seeing what happens if the .so itself tries to use
libdl to reopen the main program.
Short answer: works on Linux, but at run- (not load-time) only.
Longer answer: if a .so has an explicit dependency on the main program,
i.e. a procedure marked extern, an attempt to load it using
dlopen(...RTLDLAZY) will fail (return zero as a handle). The error
message refers to an entry point of the form library_proc_types rather
than program_proc_types, and I've not managed to override that using
extern or extern/name in a way that makes everything happy.
Using LoadLibrary() -> dlopen() inside the .so, passing an *empty*
string representing the main program, appears to allow exported entry
points to be accessed (i.e. a shared library can access a procedure in
the main program in exactly the same way that a main program can access
a procedure in a shared library).
One thing that would be useful would be if DynLibs had a "get last
error" function. I've implemented this myself for Linux and Windows and
find it indispensable.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
