GLib makes various assumptions about aliasing throughout its codebase,
and compiling with -fstrict-aliasing has been demonstrated to cause
problems (for example, bug #791622). Explicitly disable strict aliasing
as a result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
SystemTap tapsets are architecture-specific, as they include the full
path to the .so file for each probe they reference. Hence, we should
install them in an architecture-specific path, or multiarch systems will
suffer from collisions between them.
A better long-term solution, using $libdir rather than the
non-architecture-specific $datadir, is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264; but this will do
for now.
https://bugzilla.gnome.org/show_bug.cgi?id=662802
Passing -z nodelete without the shared library flags on Solaris results in
ld: fatal: option '-z nodelete' is incompatible with building a dynamic executable
which causes the configure test to falsely report its not supported.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776195
Specifically controlling the location of this file, rather than simply
using $libdir, allows one to avoid conflicting with the same default
location as the gnulib localcharset module uses.
https://bugzilla.gnome.org/show_bug.cgi?id=346816
It is outdated and no longer effectively used. It was originally in
place to prevent rebuilding generated files (from a tarball) if the
right build tools (awk, Perl, indent) were not available. However, we no
longer use indent, we have hard-required awk for a while, and the only
places the @REBUILD@ substitution was still used were for
glib-genmarshal, which has recently been rewritten in Python (so no
longer depends on whether Perl is available).
Drop the whole lot.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=694723
We're eventually going to drop Autotools, but in the meantime we should
probably use idiomatic options and reduce warnings.
GLib is pretty much already safe for subdir-objects to be enabled,
except in the GIO tests, where the build references files that are
generated in a different level. For that, we can use the same solution
employed by GTK+, and link the appropriate file in the right
sub-directory.
https://bugzilla.gnome.org/show_bug.cgi?id=788989
It adds support for source-specific multicast IGMPv3.
Allow receiving data only from a specified source when joining
a multicast group.
g_socket_join_multicast_group_ssm can be called multiple times
to allow receiving data from more than one source.
Support IPv4 and IPv6.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=740791
Instead of requiring --enable-compile-warnings or
--enable-compile-warnings=yes, allow any value which is not ‘no’. This
enables compile warnings for --enable-compile-warnings=maximum or
--enable-compile-warnings=error, which are common values for other GNOME
projects. While we don’t change our behaviour for [yes, maximum, error],
at least it means the warnings are enabled now, rather than disabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Python 2.7 is the last stable release of the 2.x series, as per PEP
404: http://legacy.python.org/dev/peps/pep-0404/
Python 2.7 is also 7 years old, and maintained until 2020.
We're in the process or rewriting other tools in Python to reduce the
number of dependencies of GLib.
Additionally, making glib-genmarshal a Python script reduces the
complexity when cross-compiling, as we don't need a native build to
generate the marshallers.
https://bugzilla.gnome.org/show_bug.cgi?id=784528
We need mnt_unref_table() in order to use libmount, but we also need to
keep the fallback code for installations of libmount without a
pkg-config file.
https://bugzilla.gnome.org/show_bug.cgi?id=782628
This adds support for Visual Studio 2017 by updating the autotools files for
copying and updating the Visual Studio 2010 project files.
Since the toolset version of Visual Studio 2017 is no longer in the form
of $(MSVC_VER_SHORT)0, we need to specify the full number, but this is a
rather simple change we have here. Note that Visual Studio 2017's CRT
aims to be compatible with the 2015's CRT, so it should be possible to
use 2017-compiled code with the 2015-compiled ones.
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
