Solution: add macro in ZMQSourceRunChecks.cmake and optionally
include the TIPC sources if the support is available.
More importantly, only run the TIPC tests if the support is there.
A Visual Studio build from master (commit id: dac5b45dfb) using the v140_xp toolset yields a binary that is not XP compatible.
Two libraries contain exports that cannot be found:
- IPHLPAPI.DLL : if_nametoindex
- KERNEL32.DLL : InitializeConditionVariable
The latter export is already dealt with in the file './src/condition_variable.hpp'; however this requires setting the _WIN32_WINNT pre-processor definition.
I am not experienced enough to figure a work around for the 'if_nametoindex' method, so I have created a new pre-processor definition 'ZMQ_HAVE_WINDOWS_TARGET_XP' and removed the calling of the function with the limitation that these builds cannot handle a IPv6 address with an adapter name.
To make it easier for people targeting XP with an MSVC build I have modified the MSBuild property file to add/modify the pre-processor definitions if they are building using a XP targeting tool set; such as v140_xp.
* Added a new .gitignore file for excluding Visual Studio build output any popular plug-in generated content. (This was copied from the GitHub project https://github.com/github/gitignore).
* Removed the basic ignore settings from the root folder in favour of more precision within the subfolder's .gitignore file
* Added the new VC compiler's experimental Intellisense database file
All the older (vs2010 -> vs2013) projects had copies of the Visual Studio 2015 MSBuild applied to them when running the 'configure.bat' batch file. Any modifications to a property sheet was not applied to the other Visual Studio versions' projects unless the batch file was re-executed.
* Modified the older projects to reference the Visual Studio 2015 property sheets so changes are immediately applied
* Removed the batch file copy steps (which left the repository very dirty after execution)
Solution: update builds/valgrind/valgrind.supp to ignore glibc's
__libc_freeres calls. This code runs after the program exits, and
tries to de-allocate memory allocated internally by glibc, so it has
nothing to do with libzmq code. This suppression is added by default
in newer versions of Valgrind, not yet available on older
distributions.
Solution: remove temporarily until proper message limits have been
implemented, then a more granular test case can be added without
such high requirements which are problematic in embedded environment,
build systems, VMs and CI systems
Solution: Modified projects to create PDB file for RELEASE targets
- also spread precompiled settings to all DevStudio solution versions
This change affects Windows builds only
Solution: The Coverity Static Code Analyzer was used on libzmq code and found
many issues with uninitialized member variables, some redefinition of variables
hidding previous instances of same variable name and a couple of functions
where return values were not checked, even though all other occurrences were
checked (e.g. init_size() return).
Solution: Use CMD.EXE environment variable to extract DevStudio version
number and build using it. This even supports machines with multiple
DevStudio versions installed, as long as the build for each version is
done on a separate window with the correct environment.
If multiple version builds are desired from a single CMD.EXE, edit the
buildall.bat file to uncomment the build statements for each specific
version desired.
Gyp needs its own platform.hpp; there is no way to delete this
file automatically.
Solution: copy gyp's platform.hpp into src, so that things build
properly no matter what the starting state. If you build with gyp
and then try to build using autotools' makefile, you'll get an
error from the platform.hpp.
There were numerous small issues with test cases:
- some lacked the right source file header
- some were not portable at all
- some were using internal libzmq APIs (headers)
Solution: fixed and cleaned up.
Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.
To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.
It all seems to work now. Next up, OS/X and Windows :)
This is rather insane since the code knows well enough what systems
support if_nametoindex. I blame this on over-use of autotools early
in libzmq's days.
Anyhow, this breaks gyp builds on OS/X.
Solution: add ZMQ_HAVE_IFADDRS to build/gyp/platform.hpp for OS/X.
Solution: establish a matrix of CI options. On one axis we have the
build system (autotools, cmake, android) and on the other axis we
have the encryption options (tweetnacl, libsodium or none).
I'm adding gyp support so that we can easily pull in libzmq
and other C/C++ projects into gyp packages, especially via
node-gyp.
Solution: add gyp definition
This works only for Windows, OS/X, and Linux. We set a single
macro in project.gyp according to the system, and the rest is
done in builds/gyp/platform.hpp. The values in that file are
not dynamic. Your mileage will vary.
- they have no copyright / license statement
- they are in some randomish directory structure
- they are a mix of postable and non-portable files
- they do not conform to conditional compile environment
Overall, it makes it rather more work than needed, in build scripts.
Solution: clean up tweetnacl sauce.
- merged code into single tweetnacl.c and .h
- standard copyright header, DJB to AUTHORS
- moved into src/ along with all other source files
- all system and conditional compilation hidden in these files
- thus, they can be compiled and packaged in all cases
- ZMQ_USE_TWEETNACL is set when we're using built-in tweetnacl
- HAVE_LIBSODIUM is set when we're using external libsodium
Took me over 8 hours to track down the cause of bizarre link
errors when building with libsodium. The VS project files are
not simple things.
Note to self and other maintainers: when someone is obviously
out of their depth, do not merge their changes to build scripts
without cynical appraisal.
Solution: undo the damage.
Caused by error in last commit which used HAVE_LIBSODIUM instead
of HAVE_SODIUM.
Solution: use HAVE_LIBSODIUM as we do in other configure scripts.
The project is called 'libsodium' and not 'sodium'.
There is an option to enable/disable libsodium via the Visual Studio
UI. This is not practical for command-line usage (via msbuild).
Solution: add configure.bat that searches for libsodium in sibling
directory to libzmq; if it finds it, defines HAVE_LIBSODIUM 1.
This is consistent with zproject, which has the same problem and
is getting the same solution for all dependency resolution on
Windows.
Note that this approach also provides a way to support tweetnacl
via a configure option.
Also, removed duplicate props files and re-copy in configure.bat
as it was an insane nightmare to update these by hand. (and not
clear that they were identical. Now it's forced.)
I hope restoring this from a previous version doesn't do any damage, it
is missing in the current version of this repository and is vital for
the lib to compile anywhere.
Solution: specify the necessary EXTRA_DIST
I added a Makefile.am in builds that covers all systems except msvc,
which already has a Makefile.am that does this.
Fixes#1505
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
I attempted to fix up the properties files manifests in the Makefile,
but neglected the end-of-line escape characters. It was good enough
to pass whatever make dist on Linux did, but I had no Windows build
env to test in. The broken change was in commit de4a442.
Signed-off-by: Dan Mick <dan.mick@inktank.com>
Solution: increased to 4096 by default for all MSVC builds, for MinGW,
and for CMake.
Note: this is a speculative change, it needs confirmation before we
can keep it. Particularly, there is some doubt that changing this in
libzmq will affect upstream applications using libzmq.dll.
Updated:
builds/zos/README.md: Updated with portability notes resulting
from building zeromq/libzmq/master as of 2014-07-23 on z/OS
UNIX System Services.
Current z/OS UNIX status: all expected tests pass, except
"test_proxy", which hangs and times out.
Updated:
builds/zos/runtests: Extract tests to run from tests/Makefile.am
at runtime, rather than hard coding tests list (to simplfy
later maintenance). test_*_tipc is excluded as BUILD_TIPC is
not defined on z/OS UNIX System Services. XFAIL_TESTS are also
excluded, following current logic in tests/Makefile.am
Updated:
builds/zos/cxxall: Defines ZMQ_HAVE_ZOS for platform portability;
define ZMQ_USE_POLL _instead_ of ZMQ_FORCE_POLL, due to change
in src/poller.hpp since ZeroMQ 4.0.x branch
Updated:
builds/zos/README.md: Outlined process to transfer source from
GitHub to z/OS UNIX System Services, including character set
conversion for the source
Updated:
README.md: describes process of building/using DLL
makelibzmq: Build DLL as well as static library (unless BUILD_DLL=false)
maketests: Dynamically link to ../src/libzmq.so if present
runtests: Explicitly place ../src at start of LIBPATH
makeclean: Also remove files created for DLL
cxxall: Bumped updated date to reflect last edit
builds/zos includes:
README.md: Overview of z/OS UNIX System Services port (Markdown)
makelibzmq: Compile src/*.cpp and make libzmq.a
maketests: Compile tests/*.cpp and make test_* executables
runtests: Run tests/test_* executables and report results
makeclean: Remove built files
zc++: /bin/c++ wrapper supplying required build arguments
cxxall: run zc++ for all *.cpp files in directory
platform.hpp: pre-generated (and edited) src/platform.hpp for z/OS
test_fork.cpp: updated tests/test_fork.cpp that completes on z/OS
The decision about the poller mechanism to use (select, poll, ...)
was done twice: once by the build system and once by the code in
poller.hpp. As the build-system can actually detect the mechanisms
available, prefer that result to the hard coded defaults in
poller.hpp.
At the same time, remove the duplicate detection of select() vs.
poll()-variant from proxy.cpp, signaler.cpp and zmq.cpp.
This patch has not been tested on many build platforms: especially
the cmake build needs testing / patching. For the other builds,
hard code the result as these these are all Windows platforms.
Added some missing (but existing in branch) files to libzmq11 project needed
to compile as static library by VS2012 (at least), and fixed some warnings.
One warning remains in raw_decoder.cpp, which I'm leaving for now because I'm
not sure how project owners would like to fix it.
- New ZMQ_STATIC flag to enable "libzmq.lib" Windows static library (or "libzmq_d.lib" in Debug mode).
- ZMQ_STATIC needs also to be defined by projects using static linking against "libzmq.lib"
- New StaticDebug & StaticRelease configurations for libzmq Win32 projects under MSVC 2008 & 2010
- Tested with Visual Studio 2008 Express under Windows 7, and Visual Studio 2010 Express under Windows 8.
- when compiling for Windows CE, a C++ project must define the preprocessor definitions: UNDER_CE=$(CEVersion),_WIN32_WCE=$(CEVersion)
- choosing the "_WIN32_CE" form for uniformization with "_WIN32" and "_WIN32_WINNT" already used in libzmq (boost is using both forms)
- see http://msdn.microsoft.com/en-us/library/ee479161(v=winembedded.60).aspx
MSVC build fails with linking errors for unresolved symbols SetSecurityDescriptorDacl and InitializeSecurityDescriptor in signaler.obj
Adding the relevant link library (Advapi32.lib) to VCLinkerTool fixes this (tested MSVC2010 on XP and Win7)
Without the LinkDLL statement, command-line compile using vcbuild attempts to compile EXE and complains about entrypoint
The LinkDLL statement forces the linker to produce desired output
File decoder.cpp does not compile with Visual C++ 2008:
1>c:\tmp\libzmq\src\decoder.cpp(117) : warning C4003: not enough actual parameters for macro 'max'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2589: '(' : illegal token on right side of '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2059: syntax error : '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2143: syntax error : missing ';' before '{'
This error is caused by the precense of a macro 'max' when including
'windows.h'. To solve this problem, the preprocessor macro /DNOMINMAX must
be specified.
* Added two new files: errno.hpp and errno.cpp. They are required to use errno functionality on WM.
* zmq.cpp, msg.h: removed inclusion of errno.h because it is included in zmq.h that is also included by .cpp.
* windows.hpp: process.h is included only for desktop builds.
* thread.cpp: on CE CreateThread is used instead of __beginthreadex
* socket_base.cpp, clock.cpp: on CE include cmnintrin.h instead on intrin.h
* signaler.cpp: on Windows should use special macro around event name (for unicode builds)
* err.hpp: make it include errno.hpp (my file) instead on errno.h when building for CE
* err.cpp: use FormatMessage when building for CE (because CE does not have ANSI API functions)
* zmq.h: do not include errno.h whe building for CE
* libzmq.vcproj: add tro new files
These include configurations for both Win32 and x64 platforms. All project
settings have been normalised in property sheets (the ".props" files under
builds/msvc/properties) to simplify maintenance. Build artefacts are all
generated in platform-specific subfolders of bin, lib and obj directories.
Also enables the use of precompiled headers with MSVC10.
This significantly reduces the time required to compile libzmq with Visual
Studio on Windows. It should have no impact on other platforms.
Signed-off-by: Stuart Webster <sw_webster@hotmail.com>
