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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
