Re: Using linker scripts with dlopen

[Roland McGrath <roland at hack dot frob dot com>]

> I wasn't aware of <gnu/lib-names.h>, but please help me understand the
> practical difference between the automatically generated include file
> and the specific SONAME I can get by reading the linker script. My
> impression is that they have the same information, but the include file
> is intended for the C preprocessor and the linker script is intended for
> the linker. It still boils down to how one calls and links to a shared
> library from C.

In practice they may be the same information, but in specification the
<gnu/lib-names.h> macro values are the actual information you should be
using (the SONAME), while the linker script refers to file names that may
or may not match the SONAME that is what is proper to pass to dlopen.
Another practical difference is that these linker scripts are hand-written
source files, so to parse them you need to be quite robust, while
<gnu/lib-names.h> is machine-generated and so you are somewhat safer in
assuming its exact format.  Better than parsing either of them is to use
the C preprocessor on <gnu/lib-names.h> to emit something that is exactly
what you need in a form that is most convenient for you to parse.

None of this gets to the notion you suggested of making dlopen do anything
at all like any of that, which is just a non-starter.  (It's a C interface,
and using the <gnu/lib-names.h> macros is the proper way to use it in C;
end of story.)

> I still get back to the same requirement: How can I dynamically call the
> shared function? You are telling me that I have to be careful because
> the ABI might be different. Is that a significant concern when I'm
> calling a well-known function using the platform's calling sequence?

If the function is "read", then it probably isn't.  For the general case,
there are varying function signatures and symbol versioning to contend with.