Solution: calculate from CMAKE_SYSTEM_VERSION
Problem: CMAKE_SYSTEM_VERSION might be newer than Windows SDK Version
Solution: limit _WIN32_WINNT value to Visual Studio default Windows SDK version
Solution: detect cacheline size for aligment purposes at build time
instead of hard-coding it, so that PPC and S390 can align to a value
greater than the 64 bytes default.
Uses libc getconf program, and falls back to the previous value of 64
if not found.
Solution: use requires.private, which pkg-config expands recursively
so that dependencies of dependencies can be linked against when
using pkg-config --static
- MacOS version requires CMake version 3.0.2 (because of policy CMP0042)
- Add option to build instrumented binaries with Address Sanitizer
- Add option to select compiler intrinsics for atomic ops
- Only build docs on request (saves build time)
- Lowercase all commands
- Unify indent to 2 spaces
- Remove spaces around brackets
- Remove repitition of condition in else(...) and endif(...)
Note: (re-)running CMake did not change the content of the generated files
* Problem: No CI for mingw64
Adding CI support for mingw64 to appveyor.yml
Reason: To help address the issue:
Several checks fail under 64-bit MinGW on Windows when running make check #3185
* Problem: Docs do not build with mingw64, dll already in right place
Turning off WITH_DOC for mingw64
Removing copy command for mingw64 and cygwin64 (it now seems to be directly built in "bin" directoy)
Solution: Use cmake's libdir variable to ensure that the pkgconfig file
ends up in the correct lib/lib64 directory. This matches the autotools
behaviour.
Solution: ignore tautological-constant-compare warnings, as they
might be useless on 64 bit but they are not on 32 bit where sizeof
size_t != sizeof uint64_t
Problem: When building libzmq with CMake, the installed libzmq.dylib
has a relative install name (otool -D libzmq.dylib) on MacOS. This
is a regression against building via autotools which sets an
absolute install name. Effectively, the CMake built libzmq.dylib
is rendered useless if installed in non-system directories and
used in environments without explicit DYLD_LIBRARY_PATH mgmt. For
example running any of the installed executables currently fails:
$ /some_install_prefix/bin/inproc_lat
dyld: Library not loaded: libzmq.5.dylib
Referenced from: /some_install_prefix/bin/inproc_lat
Reason: image not found
Trace/BPT trap: 5
Solution: Best practice is to install relocatable dylibs.
On MacOS this means setting an install name with a special prefix,
e.g. @rpath/libzmq.dylib, and adding the relevant search paths
to the embedded rpath list. In this patch the necessary CMake options
are added to generate the desired relocatable dylibs. Find more
information on: https://cmake.org/Wiki/CMake_RPATH_handling.
Solution: revert the revert!
Revert "Problem: regression in 4.2.3 went unnoticed, want to release 4.2.5"
This reverts commit 5f17e26fa4c60c3de0282d1b6ad1e8b7037ed57a.
Solution: remove objects optimisation in library build (similar to #2860)
and set PUBLIC compile definitions on all static builds instead of MSVC
only.
Solution: change case of `WinSock2.h Iphlpapi.h Rpc.h` to match the
files on disk. This is only noticeable when cross-compiling from a
case-sensitive system so wouldn't get picked up in MSVC or mingw
builds running on a windows machine.
MSDN uses capitalised versions in prose and lowercase in code examples:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms737629(v=vs.85).aspxFixes#2978, the missing library message is a little misleading.
This fixes an error with the cmake install configuration, which
attempted an invalid copy of a .pdb file on windows, when the
BUILD_SHARED option is disabled.
