Hello, I'm using CMake 2.4.6 on a PowerPC iBook running MacOS X 10.4.8 and I found some issues with building both shared and static libraries and with linking to static libraries using CMake.
I have attached a very simple example project to this e-mail that can be used to demonstrate the problems. If you have a look at the CMakeLists.txt in the example, you can see that it states that both a shared and a static library should be built from the same sources plus an executable should be built and linked against the static version of the library. Now if you create a build directory for the project using CMake and run make in it, both libraries and the executable are built -- but somewhere in the build process the dynamic library is deleted again, so it is gone from the output directory when the build finishes! Of course, as the dynamic library has disappeared, the executable that is produced is linked against the remaining static library, which is also what the CMakeLists.txt specifies. But now, in order to keep both libraries try the following in the build directory: make clean make lib_shared mkdir tmp mv liblib.dylib tmp make lib_static mv tmp/liblib.dylib . And then build the executable that is specified to link against the static version of the library: make use If you check the resulting executable with otool -L, you will see that it is now dynamically linked against liblib.dylib instead of statically against liblib.a. I consider this seriously buggy behaviour. First of all I don't like it that the build system magically wipes out one of the library targets I ordered it to create. But the more serious problem is the linkage issue: As CMake tries to be clever and converts any absolute path to a library passed to TARGET_LINK_LIBRARIES into a combination of -L and -l flags for the linker, it is completely impossible to link against a static library on MacOS X if a dynamic library of the same name exists anywhere on the library search path! The MacOS X linker always prefers dynamic libraries over static ones if it can find them anywhere. Is there any portable workaround for this problem? Of course I can always manually handle the linker flags correctly, but that's tedious and exactly the type of thing I want to avoid by using CMake. cu, Thomas Chust
cmakebug.tar.gz
Description: Unix tar archive
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake