Note that there are some explanatory texts on larger screens.

plurals
  1. POC++, is linking order standardized?
    text
    copied!<p>On my linux box, I have 2 libraries: </p> <pre><code>libfoo1.a and libfoo2.a </code></pre> <p>and they both contain an implementation of </p> <pre><code>void foo(int) </code></pre> <p>and my main program calls foo:</p> <pre><code>int main() { foo(1); return 0; } </code></pre> <p>I compiled the program two ways using g++</p> <pre><code>g++ main.cpp libfoo1.a libfoo2.a -o a1.out g++ main.cpp libfoo2.a libfoo1.a -o a2.out </code></pre> <p>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.</p> <p>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?</p> <p>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).</p> <p>PPS: To put it in <em>real</em> 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. </p> <p>Sorry for the length of post.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload