See previous commit; same reasoning behind the commit, except that these
sources weren’t (yet) causing `make distcheck` to fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of messing around with EXTRA_*_SOURCES and manually handling .lo
files, why not just add gwin32.c to the GLib sources conditionally?
This will hopefully fix `make distcheck` failing due to gwin32.Plo not
being generated in the sub-builddir≠srcdir stage, due to depcomp
inexplicably not generating it. (Note that it is correctly generated in
non-distcheck builds.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When compiling third-party projects with -Wbad-function-cast, the inline
g_atomic_pointer_get() implementation which uses C11 __atomic_load*()
calls on GCC was causing compilation errors like:
error: cast from function call of type ‘long unsigned int’ to non-matching type ‘void *’
While we don’t want to compile all of GLib with -Wbad-function-cast, we
should support its headers being included in projects which do enable
that warning.
It doesn’t seem to be possible to cast away the warning (e.g. by casting
the function’s result through (void)), so we have to assign to an
intermediate integer of the right size first.
The same has to be done for the bool return value from
__sync_bool_compare_and_swap(). In that case, casting from bool to
gboolean raises a -Wbad-function-cast warning, since gboolean is
secretly int.
The atomic tests have been modified to enable -Wbad-function-cast to
catch regressions of this in future. The GLib build has conversely been
modified to set -Wno-bad-function-cast, just in case people have it set
in their environment CFLAGS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1041
We don’t have the same dependency in the Meson build, and we don’t
depend on Perl any more. See #1332. The last remaining Perl script,
gen-unicode-tables.pl, is only ever run manually when we update our
Unicode character database. It will be ported to Python in due course.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1332
PCRE >= 8.31 is required for PCRE_INFO_MAXLOOKBEHIND usage, introduced
in commit 6fbb146342 (2013/07).
regex can also make use of the PCRE_NO_AUTO_POSSESS feature from PCRE
8.34, but this is optional and properly guarded already.
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen.
In this case we are simply calling fork() in order to quickly call exec(),
which will throw away the entirity of the duplicated VM, so we should
look for ways to avoid the overcommit check.
The well known solution to this is to use clone(CLONE_VM) or vfork(), which
completely avoids creating a new memory address space for the child.
However, that comes with a bunch of caveats and complications:
https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234https://ewontfix.com/7/
In 2016, glibc's posix_spawn() was rewritten to use this approach
while also resolving the concerns.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9ff72da471a509a8c19791efe469f47fa6977410
I experimented with a similar approach in glib, but it was not practical
because glibc has several items of important internal knowledge (such as
knowing which signals should be given special treatment because they are
NPTL implementation details) that are not cleanly exposed elsewhere.
Instead, this patch adapts the gspawn code to use posix_spawn() where
possible, which will reap the benefits of that implementation.
The posix_spawn API is more limited than the gspawn API though,
partly due to natural limitations of using CLONE_VM, so the posix_spawn
path is added as a separate codepath which is only executed when the
conditions are right. Callers such as gnome-shell will have to be modified
to meet these conditions, such as not having a child_setup function.
In addition to allowing for the gnome-shell "Cannot allocate memory"
failure to be avoided, this should result in a general speedup in this
area, because fork()'s behaviour of cloning the entire VM space
has a cost which is now avoided. posix_spawn() has also recently
been optimized on OpenSolaris as the most performant way to spawn
a child process.
There seems to be little point in substituting the version number into
README (using autotools). Rename it to README.md and distribute that
verbatim (with autotools and Meson) instead.
Autotools still requires that README exists, so leave a stub README file
in place which redirects people to README.md. This can be dropped when
we drop autotools support.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We have not updated nor used this script for a long time, and nowadays
Meson makes it much easier to build on Windows for either Visual Studio
or MinGW, even straight from a GIT checkout, so it's about time that we
drop the glib-zip script from the source tree.
Autoconf macro AC_HEADER_MAJOR doesn't define a macro in config.h when
major is defined in sys/types.h. This was not a problem because major
is assumed to be always available. However, commit aefffa3fbc
changes this assumption in order to fix build on systems without major,
which causes code using major to be disabled on systems putting major
in sys/types.h.
This commit defines a new macro MAJOR_IN_TYPES for both autotools and
meson builds to make major useful on these systems again.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
See commit 4c2928a544 for why checking AT_SECURE is preferable compared
to UID checks as currently done in the fallback case.
getauxval() was added with glibc 2.16
While glibc <2.19 didn't provide a way to differentiate a 0 return value from an error,
passing AT_SECURE should always succeed according to
https://sourceware.org/ml/libc-alpha/2014-07/msg00407.html
I've added an errno check anyway, to be on the safe side.
It was added in 4c2928a544 to potentially enable accessing
AT_SECURE through __libc_enable_secure, but was never enabled.
Newer glibc provides getauxval(AT_SECURE) which should be used instead.
Add a TODO note for that.
ENABLE_GC_FRIENDLY_DEFAULT was supposed to set the default for the gc friendliness
while still allowing to force enable it at runtime with G_DEBUG=gc-friendly.
With commit 943a18b564 (6 years ago) things were changed to always set it
according to the content of G_DEBUG in glib_init(), making the default unused.
Since nobody complained since then just remove the macro and the build option.
Try and ensure that people don’t push code with misleading indentation
in future. This should give fairly few false positives.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There is no reason to disable this linker flags, and we are not going to
add this option in our meson build system, so remove it from autotools
too to be on par. If anyone complains with a valid use-case we can add
them back.
Keeping -Bsymbolc for now because it is used for refdbg and Debian has a
package that build glib with that flag.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
Supports %OB (alternative, standalone, nominative) month name along
with the old %B (primary, in a complete date format context, genitive)
month name. Similarly %Ob and %Oh for abbreviated month names.
Depending on the underlying operating system uses nl_langinfo()
or provides our custom implementation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to add test case
comment and bug reference.)
https://bugzilla.gnome.org/show_bug.cgi?id=749206
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
