Since commit 96ebcee8c4, we don’t actually need libmount 2.28. Lower our
dependency to 2.23 so that we can continue to build against CentOS 7.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
Building against libmount installed into a non-default prefix wasn’t
working, as we were using #include <libmount/libmount.h> rather than
the correct #include <libmount.h> — all the mount.pc pkg-config files
set `Cflags: -I${includedir}/libmount`.
Fixing this while retaining the fallback support for versions of
libmount without a pkg-config file would have been tricky (we would need
to work out a suitable -I flag to set in LIBMOUNT_CFLAGS) to still be
able to use the correct #include path). Thankfully, libmount gained
pkg-config support a long time ago, so I think we can safely drop the
fallback code. In particular, Debian Jessie, Ubuntu Trusty, and CentOS 5
all ship a mount.pc file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793288
res_query() uses global state in the form of the struct __res_state
which contains the contents of resolv.conf (and other things). On Linux,
this state seems to be thread-local, so there is no problem. On OS X,
however, it is not, and hence multiple res_query() calls from parallel
threads will compete and return bogus results.
The fix for this is to use res_nquery(), introduced in BIND 8.2, which
takes an explicit state argument. This allows us to manually store the
state thread-locally. If res_nquery() isn’t available, we fall back to
res_query(). It should be available on OS X though. As a data point,
it’s available on Fedora 27.
There’s a slight complication in the fact that OS X requires the state
to be freed using res_ndestroy() rather than res_nclose(). Linux uses
res_nclose().
(See, for example, the NetBSD man page:
https://www.unix.com/man-page/netbsd/3/res_ninit/. The Linux one is
incomplete and not so useful:
http://man7.org/linux/man-pages/man3/resolver.3.html.)
The new code will call res_ninit() once per res_nquery() task. This is
not optimal, but no worse than before — since res_query() was being
called in a worker thread, on Linux, it would implicitly initialise the
thread-local struct __res_state when it was called. We’ve essentially
just made that explicit. In practical terms, this means a
stat("/etc/resolv.conf") call per res_nquery() task.
In future, we could improve this by using an explicit thread pool with
some manually-created worker threads, each of which initialises a struct
__res_state on spawning, and only updates it on receiving
the #GResolver::reload signal.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792050
The chmod of all the scripts we generate from a template via configure
is necessary because configure will not preserve the bits of the
template when generating a new file.
There's no explanation for it, and you have to hunt it down the commit
history. Since Meson does the right thing, we added the executable bit
on the templates, but we cannot remove the AC_CONFIG_COMMANDS macro from
the Autotools build without breaking it. Let's document this, to avoid
nasty surprises.
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.
So that we don't get "deprecation" (availability) warnings for
new functionality of GLib 2.51/2.52.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The libmount code produces somewhat different results than the older
Linux code that would parse /proc/mounts; for example, bind mounts
appear in the libmount output. To try and get as many GLib users
as possible to have the same behavior, on Linux, make GLib error out
on missing libmount unless --disable-libmount is passed.
https://bugzilla.gnome.org/show_bug.cgi?id=771438
This is causing trouble with flatpaks because the org.gnome.Platform
runtime does not bundle libmount, while the org.gnome.Sdk does it.
As this probably requires a change in the freedesktop.org Yocto base,
we disable this support by default for now as a temporary measure
until it can be properly reviewed by someone who knows those bits
better, probably Alex Larsson.
https://bugzilla.gnome.org/show_bug.cgi?id=769284
Talk to the journal ourselves using sendmsg() instead of linking
against libsystemd for sd_journal_sendv(). At the same time, we
can also avoid excessive copying.
The motivation for dropping the dependency is that we can
then use structured logging e.g. in a flatpak sandbox where
libsystemd may not be present in the runtime.
The code here is inspired by similar code in libvirt.
In parallel with g_log(), add a new structured logging API, based around
g_log_structured() and various helper functions which are exposed
publicly to allow programs to build their own logging policies easily,
without having to rewrite a lot of gmessages.c because it’s all
internal.
See the expanded documentation at the top of gmessages.c for some
rationale. See the g_log_structured() documentation for some example
code.
https://bugzilla.gnome.org/show_bug.cgi?id=744456
Add filesystem attribute to detect remote filesystems in order to
replace hardcoded filesystem types in GtkFileSystem. Set this attribute
also for GLocalFile appropriately.
Bump version to 2.49.3, so that early adopters of new API have a version
number to target.
We now prefer pthread_setname_np when available, and don't
need the linux specific API anymore. Also change the test
for this functionality to use pthread_getname_np.
The current statfs() compilation tests all fail because statfs() expects
the first argument to be non-null. Pass a dummy path instead of NULL to
satisfy the compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=764574
... from glib-gen-srcs.[vsprops|props].in to
glib-version-paths.[vsprops|props].in, and instead let autotools generate
glib-version-paths.[vsprops|props] rather than
glib-gen-srcs.[vsprops|props], as this will need to be referenced for
other items as well, namely generating the .pc files which will become
useful for introspection builds.
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Commit 212e4232e7 introduced a big update
of gnulib. Necessary changes to configure.ac from old gnulib commit
e8e63d1b31bca6c82713cba490b21a861abb24b5 have been forgotten. Actually
available functions are not discovered by autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=759134
This example has been causing on-and-off build breaks for quite some
time. In this case, the code for copying the generated content into the
main docs of GIO is causing problems with srcdir != destdir builds (due
to the files also being copied from the read-only srcdir during
distchecks).
We could probably work around this problem yet again, but since there is
no real benefit to having this content included, so let's remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
It's been a long time since we've been unconditionally saying "static
inline" in GLib headers without complaints so it's safe to assume that
all compilers that we care about support this.
One thing that is not yet totally supported is the unadorned use of the
word "inline". Depending on the flags (-std=c89, for example), even GCC
will complain about this. Detect missing C99 support and define
"inline" to "__inline" in that case. Some research shows "__inline"
appears to be the most widely-supported keyword here, but we may need to
tweak this if we get some reports of breakage.
Clean up all of the configure checks around this and define G_CAN_INLINE
unconditionally. Unfortunately, we must assume that some people are
still using G_IMPLEMENT_INLINES, we must continue to implement that
(including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
requested.
It is not our intent to break existing users of the old-style
G_INLINE_FUNC approach and if that has happened, we may need to make
some further adjustments.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
It's a platform-specific macro, so it belongs in glibconfig.h.
This ensures that g-ir-scanner will not pick the wrong definition
for introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=757294
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
Add support for receiving multiple messages with a single system call,
using recvmmsg() if available. Otherwise, fall back to looping over
g_socket_receive_message().
This adds new API, g_socket_receive_messages(), and corresponding unit
tests.
https://bugzilla.gnome.org/show_bug.cgi?id=751924
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
