In C++, static library A is linked into dynamic libraries B and C. If a class, Foo, is used in A which is defined in B, will C link if it doesn't use Foo?
I thought the answer was yes, but I am now running into a problem with xlc_r7 where library C says Foo is an undefined symbol, which it is as far as C is concerned. My problem with that is Library C isn't using the class referencing it. This links in Win32 (VC6) and OpenVMS.
Is this a linker discrepancy or a PBCAK?
New info:
B depends on C, but not visa-versa.
I'm not using /OPT:REF to link on Windows and it links without issue.
When you statically link, two modules become one. So when you compile C and link A into it, its as if you had copied all the source code of A into the source code of C, then compiled the combined source. So C.dll includes A, which has a dependency on B via Foo. You'll need to link C to B's link library in order to satisfy that dependency.
Note that according to your info, this will create a circular dependency between B and C.
Sounds like it's probably the linker (ld/unix), as (most versions that I've used of) ld links the libraries in from left to right - and if there is a reference in the first one that is required by a later one the usual trick is to append the first library (or any required library) to the end of the command.
It's a try it and see....
Is your link line for C including the export lib for B? If so then as Richard suggest it sounds like an ordering thing.
Another suggestion is to see if there is a linker option to ignore unreferenced symbols, if C doesn't need that functionality from A. For the Microsoft linker this achieved with the /OPT:REF switch.
The only reason why C wouldn't link is that the compiler thinks it does need the Foo symbol.
Since C doesn't refer to Foo symbols, there has to be another reason why the linker needs the symbol.
The only other reason I know of, is an export of some kind. I know only of Visual C++, so I suggest you search for some equivalent of __declspec( dllexport ) in the preprocessed files, and see what generates it.
Here's what I'd do: have the preprocessor output stored in a separate file and search it for occurences of Foo. Either it will occur as an export, or it has been referenced some way by the compiler.
If the definition of particular function is not required, then that library will not be linked during linking phase. In your case, as the definition of foo is present in the library B and not in library C. Thus the library C will not be loaded into the memory while loading the executable.
But it seems, you are using the foo() function in the library C as well, because of which you are getting the corresponding error.
