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.)
