[CMake] Specifying (partially) load order of DLLs

[Brad King]

Wheeler, Frederick W (GE, Research) wrote:
> To make sure A.dll is loaded before
> B.dll we use the following line in CMake ...
> 
> TARGET_LINK_LIBRARIES( A B )

I'm surprised that works.  Consider the case when there really is a 
dependency.  That says that A depends on B, so that B should be loaded 
first so its symbols are there when A loads.  CMake will generate A's 
link line to list B.  This means that the dll for A is linked using the 
import library for B.  I wouldn't be surprised if this actually causes 
enforcement of B loading first.

> This worked fine in CMake 2.5.x, but in 2.6.1, even with the above
> line, B.dll might be loaded before A.dll (seen with the tool
> depends.exe).

What is the order generated on the link line for the application?  Any 
version of CMake should always make sure A comes before B on link lines.

What are the link lines generated for the application, and for library 
A, with the two CMake versions?

> Here is my suspicion: Cmake 2.6.1 is a bit smarter, so we don't get
> the side-effect we need.  When A depends on B, A must come before B on
> the link line for a static link, of course.  But for shared objects I
> think the order does not really matter, since the whole shared library
> is loaded.  Maybe CMake knows that, so it does not worry about the
> link-line order of DLLs?

What does the target_link_libraries command invocation for the final 
application look like?

> 1. Could my suspicion above about CMake 2.6.1 and run-time link order
> of shared objects be correct?

The only time 2.6.1 pays attention to whether a library is static or 
shared for link line generation is after it has generated a link line 
satisfying all dependencies.  It goes back and makes sure that the 
static items in the original user-specified link line for the target 
appear with the same order and multiplicity in the new link line, 
possibly by appending more items.  Shared libraries are left out of this 
analysis.  However, in your case there is a real dependency added by the 
target_link_libraries call, so the link line it generates should have 
the correct order before this final pass.

Try a 2.6.2 release candidate.  It restores the absolute enforcement of 
the original link line order that 2.4 had (though still fixes some bugs 
with what libraries are appended to the original user specification to 
satisfy dependencies).

> 2. Is there a better or more reliable way than TARGET_LINK_LIBRARIES(
> A B ) to get A.dll loaded before B.dll at the run-time linking stage?

I don't know how windows decides the load order, and I don't know how 
much the order of the import libraries on the link-time command line 
affects it.  Try artificially introducing a dependency by creating a 
symbol in one library that is referenced from the other.

-Brad