[fpc-pascal] Shared libraries and threadvars

[Mark Morgan Lloyd]

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]