On my linux box, I have 2 libraries:
libfoo1.a and libfoo2.a
and they both contain an implementation of
void foo(int)
and my main program calls foo:
int main() { foo(1); return 0; }
I compiled the program two ways using g++
g++ main.cpp libfoo1.a libfoo2.a -o a1.out
g++ main.cpp libfoo2.a libfoo1.a -o a2.out
When I run the programs, a1 is clearly using the foo() implementation from libfoo1.a, while a2 clearly used libfoo2. That is, g++ linked whichever foo() that it saw first.
My question (finally) is, is this "greedy" linking policy actually specified in the C++ standard? Or would a different compiler / platform behave differently in an implementation-defined way?
PS: To put the question in practical context, I really like the way this g++ example works. In my real application, I have a legacy libfoo2 that implements many (many!) functions, but I want to provide new implementations for a handful of them in libfoo1. On one hand I could write a whole new interface in libfoo1, implement my handful, then delegate to libfoo2 for the remainder. But I would rather void writing all that delegation code, if I can rely linker to do it for me (even for non-g++ compilers like icc).
PPS: To put it in real practical context, libfoo2 is the blas, and libfoo1 is a homebrew OpenMP implementation of a few of its routines. I'm not ready to shell out for MKL. ATLAS does not multithread the functions I want to call. It is very good at multithreading GEMM, but I need some of the quirkier routines from LAPACK to be fast too (zsptrf / zsptrs / zspr). It appears that the my cache-ignorant OpenMP implementation of these routines can do better than it's cache-tuned sequential implementation.
Sorry for the length of post.
The standard doesn't say anything about linking order. I would say it's not good practice to rely on whatever order your compiler uses.