The default OS X 10.4 linker incorrectly searches for dependencies of
linked shared libraries only under the -isysroot location. It fails to
find dependencies of linked shared libraries in cases such as the
ExportImport test. It produces errors like:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
libtestLib3Imp.dylib
referenced from: /.../ExportImport/Root/lib/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _testLib3Imp
referenced from libtestLib3lib expected to be defined in
libtestLib3Imp.dylib
or with CMAKE_SKIP_RPATH off to enable install_name in the Export side:
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open dynamic library:
/Developer/SDKs/MacOSX10.4u.sdk/.../ExportImport/Export/impl/libtestLib3Imp.dylib
referenced from: /.../ExportImport/Export/libtestLib3lib.1.2.dylib
(checking for undefined symbols may be affected) (No such file or directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:_testLib3Imp
referenced from libtestLib3lib expected to be defined in
/.../ExportImport/Export/impl/libtestLib3Imp.dylib
Note how "/Developer/SDKs/MacOSX10.4u.sdk" is prepended to the dependent
library path.
Commit 2cff26fa (Support linking to shared libs with dependent libs,
2008-01-31) and commit 82fcaebe (Pass dependent library search path to
linker on some platforms, 2008-02-01) worked around the problem by
defining platform variable CMAKE_LINK_DEPENDENT_LIBRARY_FILES. It tells
CMake to link to dependent libraries explicitly by their path thus
telling the linker where to find them.
Unfortunately the workaround had the side effect of linking dependent
libraries and defeats most benefits of LINK_INTERFACE_LIBRARIES.
Fortunately OS X 10.5 and above do not need to find transitive
dependencies at all so we can avoid the workaround on Modern OS X.
Previously we linked C, Fortran, and ASM shared libraries compiled with
the HP compiler using a direct invocation of the linker (ld). This
behavior was left historically from support for an ancient HP C compiler
that did not know how to create shared libraries. Fortran shared
libraries need to be linked with the compiler to get the language
runtime library dependencies as is already done for C++.
Update the HP-UX-HP* platform information to use the compiler front end
when linking shared libraries. This works on modern HP tools and
produces correct behavior. If there is a need to support older tools
again we can add a special case for them.
...if it matches "windres", as opposed to being exactly equal to "windres"
Cross-compiling windres compilers are named something like
"i686-w64-mingw32-windres" (for example)
The User may now specific a list of file that shouldn't be
automatically handled by CPack but specified by the user.
Like %config(noreplace) or specific %attr.
The concerned files/dir lines will be removed from the set
automatically handled by CPack.
The mingw32-make tool does not handle parenthesis in the path to a
source file consistently. When CMake is installed in a typical location
like "c:\Program Files (x86)\CMake 2.8\" the mingw32-make tool fails on
the FortranCInterface detection project sometimes with errors like
>mingw32-make -f CMakeFiles\myfort.dir\build.make CMakeFiles/myfort.dir/my_module.f90.obj
mingw32-make: *** No rule to make target `x86)/CMake 2.8/share/cmake-2.8/Modules/FortranCInterface/my_module.f90)',
needed by `CMakeFiles/myfort.dir/my_module.f90.obj'. Stop.
due to parens in the path to the FortranCInterface source directory.
However, the behavior varies with the file name of build.make:
>copy CMakeFiles\myfort.dir\build.make CMakeFiles\myfort.dir\build2.make
>mingw32-make -f CMakeFiles\myfort.dir\build2.make CMakeFiles/myfort.dir/my_module.f90.obj
[ 3%] Building Fortran object CMakeFiles/myfort.dir/my_module.f90.obj
Tested with
>mingw32-make -v
GNU Make 3.82
Built for i386-pc-mingw32
Work around the problem by copying the whole FortranCInterface source
directory in to the project build tree.
2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling
1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE
bc278ce automoc: fix line length
62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing
40c5167 automoc: accept even more .moc files in non-strict mode
c207f5d automoc: also accept other files when .moc is included in non-strict mode
9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible
174bf35 automoc: move the code for finding headers into separate function
8507eae automoc: fix handling of included _p.moc files
7ada172 automoc: some more linebreaks for the warnings for better readability
3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT
4745715 Add a test case for the use of Q_PRIVATE_SLOT.
bde4edb automoc: add special handling for including basename_p.moc, with test
74ab0f6 automoc: move some code from the big parsing loop into separate functions
bc7560e automoc: add test for including a moc_abc_p.cpp file
30fd8e6 automoc: add test for including the moc file from another header
...
ae62a1c Test CMAKE_GNUtoMS option in ExportImport on MinGW and MSys
afb00fe Add CMAKE_GNUtoMS option to convert GNU .dll.a to MS .lib
61e8629 Factor makefile generator link rule lookup into helper function
a603250 Load platform files that need to know the ABI when possible
ecd8414 Fortran: Detect pointer size in gfortran on MinGW
0efe602 TinyCC: Add default compilation flags (#12605)
ec636e2 TinyCC: Add compiler info for shared libs on Linux (#12605)
1f49d72 Recognize the Tiny C Compiler (#12605)
This allows you to have more than source file with the same name but different
directories. The intermediate and configuration files are now in this same directory.
Nvcc can emit '/path' instead of '//path' which can cause a lot of grief later. We test
to see if the file exists, if it doesn't then we see if the file exists with '/'
prepended. Files that don't exist won't be added to the list.
Fix a long outstanding bug when a file in the dependency list wasn't found. This bug
wouldn't reset the dependencies, so the makefile would still want the missing file when
building. The work around was to configure twice, but this is no longer necessary.
Teach the Windows-GNU.cmake platform file to look for Visual Studio
tools matching the target ABI. Add an extra step to the link command
for shared libraries and executables that export symbols and on which a
new GNUtoMS property is set (initialized by the CMAKE_GNUtoMS option).
Tell the GNU linker to output a module definition (.def) file listing
exported symbols in addition to the GNU-format import library (.dll.a).
Pass the .def file to the MS "lib" tool to construct a MS-format DLL
import library (.lib).
Teach the install(TARGETS) command to install the MS import library next
to the GNU one. Teach the install(EXPORT) and export() command to set
the IMPORTED_IMPLIB property pointing at the import library to use the
import library matching the tools in the importing project.
Load platform files named in CMAKE_<lang>_ABI_FILES for each language
once the ABI sizeof(void*) is known. During the first configuration
this is after the test for working compiler and ABI detection checks.
During later configurations the ABI information is immediately available
because it has been saved in CMake<lang>Compiler.cmake.
Use __SIZEOF_POINTER__ which the GNU Fortran compiler defines at least
on 64-bit MinGW. Assume default size 4 on MinGW if gfortran does not
define the size.
Adding VERBATIM to the ADD_CUSTOM_COMMAND calls in the qt4 macros
ensures that paths are properly quoted when passed to the shell.
This fixes issues when building projects that contained paths with
special characters (according to /bin/sh), such as parentheses or
spaces.
Use the "-shared" option to link shared libraries. The compiler does
not support "-Wl," or "-rpath" but does know how to pass "-soname"
through to the linker.
Perform multiple separate searches in order. If ZLIB_ROOT is set search
it exclusively so it takes precedence over CMAKE_PREFIX_PATH. This
allows a user to provide -DZLIB_ROOT=/path/to/zlib/prefix on the CMake
command line to tell it exactly where to find zlib. Otherwise fall back
to a normal search.
Inspired-by: Andreas Schneider <asn@cryptomilk.org>