Better not modify copy/paster files otherwise this will regress again
later. It's better to not include valgrind.h at all when using MSVC.
This reverts commit bbcce75d4e.
Visual Studio x64 builds do not allow inline assembly code, so we need
to re-add the code that disables inline assembly when we build with
Visual Studio for x64 builds, as we did before. This is necessary when
we update the included valgrind.h.
Update our copy of valgrind.h from the Valgrind 3.13 release tarball.
This seems to include fixes for PPC and Solaris. No changes made to the
header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=736741
This ensures the uintptr_t type is defined on mingw-w64.
Fixes compile error:
make[4]: Entering directory
`/home/abuild/rpmbuild/BUILD/glib-2.42.0/gobject'
CC libgobject_2_0_la-gtype.lo
In file included from gtype.c:24:0:
../glib/valgrind.h: In function 'VALGRIND_PRINTF':
../glib/valgrind.h:5601:4: error: unknown type name 'uintptr_t'
uintptr_t _qzz_res;
^
https://bugzilla.gnome.org/show_bug.cgi?id=737143
...so that builds of GLib on x64 Visual C++ can be restored, as the build
fails in line 449 of valgrind.h as it only supports MinGW/GCC for x64
Windows and simply will not build otherwise. Make the x64 Visual C++
builds compile again by defining NVALGRIND when GLib is being built for
Windows on x64 Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=732465
This is a BSD-licenced header file that is designed to be copy-pasted
into programs. It will allow us to detect if we are running under
Valgrind and send "client requests" to it.
We will use this for a couple of reasons in upcoming patches.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
