DLL / shared library with accessing main programs variables and functions on Linux

[Frank_Illenseer]

I read about this topic on the Windows forum (see topic DLL can't see main program's shared variables) and also got it working  on Windows mainly based on the example in post #5 from IanH (Blackbelt) Wed, 12/13/2017 - 00:54  there.

My question is now how to properly do exactly the same in Linux.

I got it some how working by adding the "-Wl,--export-dynamic" when compiling the main executable, but this for sure then now exports all symbols of that (which I don't want).
So I assume there should be some equivalent of the "!DEC$ ATTRIBUTES DLLEXPORT :: var" to mark only a distinct variable or function for export also under Linux.

Additionally I like the fact of the export library being created when compiling the main executable which then is used when linking the DLL to resolve the symbols. - With this then one can also successfully check that all symbols are actually resolved already at link-time.
For Linux, I did not succeed in checking this at link time... - I get a lot of unresolved warnings when using the ld flag to output them and I do not see how to tell ld to check them where against... (i.e. would be the main executable).

Thanks,
Frank

[Steve_Lionel]

I'll just comment that Windows and Linux are VERY different in this area. On Linux, there is no use for DLLEXPORT/DLLIMPORT, and one links directly to the .so file - there is no concept of an export library. I don't know if there's a way to restrict the names visible in the .so.

[Frank_Illenseer]

Thanks, Steve.

I know about the VERY big differences between these operating systems and that is the main background of posting this question and hoping for any advice.

Just to make clear what I need to do

• I build an executable file (exe.f90 in that other example) which I compile and link on its own.
  This one references functions in a SO file (by delayed-loading at runtime via dlopen/dlsym)
• I buid a SO file (dll.f90 in that other example) which I compile and link.
  This one then needs variables/fuctions from the main executable inside the functions.

For this to work I now have found that I need to add the "-Wl,--export-dynamic" when linking the main executable which then adds all symbols to the list of dynamically exported symbols of the main executable.

FIRST QUESTION would be how to be more specific and limit the symbols being exposed to only the ones that are actually needed (which was done by the DLLEXPORT under Windows).

SECOND QUESTION would be to know how to check during linking time, if all needed symbols of the .so file can be resolved by the executable (which was done on Windows by using the export library of the exe file which was produced at link tie of the exe file).

Steve told already that there is no concept of an export library on Linux, but are there any other means of achiving one or both of my questions?

[Juergen_R_R]

Frank,

maybe check the documentation of your linker, e.g. --no-export-dynamic might be helpful.

[Frank_Illenseer]

Thanks, Juergen, but I _need_ the export of the symbols that I need to call/reference in the main executable. - So if I follow your suggestion, the .so file would not be able to see the symbols at runtime and cannot use them. - Or did I misunderstand?

I am using the GNU "ld" linker and fom its man-page I found "--dynamic-list=dynamic-list-file" to maybe be an option, but then the question would arise of how to AUTOMATICALLY generate a file that contains the REAL (potentially name-mangled) name list of the symbols at compile/link time...

[Steve_Lionel]

If I understand it correctly, linking against the .so has the effect of using an export library on Windows, in that ld will complain if it can't find the symbol.

I wonder if using dlopen for dynamic activation might be an alternative for you.