GCC / C++ Static linking for headers in a shared object

Question

-I am trying to create a shared object libfoo.so . libfoo.so is created from foo.c - Assume that I include headers static.h and Dynamic.h where in I want the compiler to
resolve the symbols for Static.h and leave the rest ie from Dynamic.h for runtime. - How do i do this ? What are the CFLAG and LDFLAG options that I need to pass. - My makefile is setup to create a shared object using the CFLAGS=fPIC , shared , W1,export-dynamic. - In the include paths i Specify the correct location for "Static.h"

Can someone help me ?

Answer 1

dlopen(), dlclose(), dlsym(), dlerror() are there for you to open external runtime libraries. You have to declare function pointers to those external objects and then resolve them at runtime.

If you simply leave references "bare" in the code, the linker will atempt to resolve the symbol. It will either resolve it or throw an error, maening you do not get an executabel image. I don't know of any linker options to exclude trying to link unresolved symbols.

Or I don't get what you are trying to do.

Answer 2

I believe the functionality you're describing is something you essentially get for free with the GCC linker. During the linking process, the linker will resolve all symbols your code references to the libraries passed to it on the command line. If the referenced symbol name is contained within a static library (a .a file) it will be 'statically' linked and if the symbol is, instead, within a dynamic link library (a .so file) it will be dynamically linked at program execution time.

Generally speaking, you shouldn't need to care whether your symbols are statically or dynamically linked as it should have zero impact on your C/C++ code. From your description, it's difficult to understand the motivation for your question but there's a chance you may have a need for explicitly loading a dynamic link library via the dlopen() system call. If the first paragraph doesn't answer your question, could you describe the general problem you're trying to solve?

Answer 3

As long as all of the dynamic symbols are accounted for in the respective headers (via externs), but potentially not declared, they can be overwritten at later points in time by the runtime linker when an application loads and defines the symbols, and the runtime linker fills in the missing bits, or barfs on the executable if one or more symbols are missing (like you have reported above with SomeRecord4init).

You can also link your application against the library (instead of using libdl, which is a pain to track down lib dependencies via many common build/analysis tools). Just using -shared and not -static in your CFLAGS will do that.

Many projects define a private and public facing APIs and fields though in C for libraries though. Maybe that's what you should do to resolve this issue?