* cmake WITH_LIBSODIUM option is broken
- Fixed the variable name in platform.hpp.in
- Fixed #if check for randombytes_close() when libsodium is used
* Fixed typo from previous commit
* Reverted compile error fix for randombytes_close()
Solution: use packages on Ubuntu and brews on OSX. The packages and
the brews are always kept up to date, so it's no use to rebuild the
libsodium stable branch manually everytime.
Solution: Provide poll() for Windows as well. This is a build option that
defaults to off as the resulting binary will only run on Windows Vista or
newer.
This is not tested with alternative Winsock service providers like VMCI,
but the documentation for WSAPoll does not mention limitations.
On my local machine, throughput improves by ~10 % (20 simultaneous
remote_thr workes to one local_thr, 10 byte messages), while latency
improves by ~30 % (measured with remote/local_lat).
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.
