From: Alan W. I. <ir...@be...> - 2014-09-23 01:59:04
|
On 2014-09-22 22:58+0100 Phil Rosenberg wrote: > Hi Alan > [...]I have located the DLLs on the lib directory and added their directory to my path, but still they don't seem to be loading. Hi Phil (taking this conversation back to the list): You need access to all the dll's in the build tree, not just a subset of them. Your words above imply dll's are _not_ being automatically located by your CMake generator in the dll subdirectory of the build tree. This has never happened before with Windows platforms that I am aware of, and ignoring our setting of the LIBRARY_OUTPUT_PATH variable could be an issue with either your visual studio generator or else CMake-3.x itself (remember our build system is currently not debugged throughly for that version compared to all the testing it has received for CMake-2.8.x). We set LIBRARY_OUTPUT_PATH using the set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll) command in the top-level CMakeLists.txt file just for the Windows case. That variable is an extreme example of a legacy variable (probably going back to CMake-2.0), and if it doesn't work for either of the two above situations, I am sure the advice we will be given by CMake devels is to use the modern counterparts of that variable instead which are some combination of setting the variables CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, and/or CMAKE_RUNTIME_OUTPUT_DIRECTORY. Here is the relevant background documentation (which you can find yourself by running "cmake --help-full") for those modern counterparts for those three different variables. "There are three kinds of target files that may be built: archive, library, and runtime. Executables are always treated as runtime targets. Static libraries are always treated as archive targets. Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms." So on Cygwin or Windows it looks like shared library dll's (created for all our shared libraries) are treated as a "runtime" target and our device driver dll's (built as MODULE libraries) are treated as a "library" target. (That last makes no sense to me. Why wouldn't MODULE libraries which are exactly dll's be treated the same as library dll's? Of course, that may simply be incorrect background documentation above, but that is what that documentation says.) So in case that documenation is incorrect, try removing set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll) and replacing it by set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll) According to the documentation the net effect of setting that variable should be to collect all executables and the dll part of shared libraries into that dll directory, but it also makes sense to me it will collect the device driver dll's (built as modules) as well in that directory. But if the build location for the device drivers is not moved from drivers to dll by the above change, then try set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/dll) instead which should work according to the documentation. And if setting one or both those variables works for you, please go ahead and commit the change so that Arjen can test it for his Windows platforms as well (which should also work according to the documentation of those variables). If no combination of setting either/both CMAKE_RUNTIME_OUTPUT_DIRECTORY or CMAKE_LIBRARY_OUTPUT_DIRECTORY locates the library and device driver dll's in the dll subdirectory, then we can only conclude that either the CMake version you are using or the generator you are using has a bug with regard to honoring the settings of CMAKE_RUNTIME_OUTPUT_DIRECTORY and CMAKE_LIBRARY_OUTPUT_DIRECTORY. Some additional tests by you with cmake-2.8.12.2 and the nmake generator would be required to sort out which, but hopefully, it will not come to that, and setting one or both the above variables will work for you. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |