The attached patch adds support for the btrfs "clone" ioctl which
makes Copy-on-Write reflinks, resulting in cheap O(1) copies when
source/destination are on the same filesystem. The ioctl itself is
quite straightforward, and GNU coreutils has had support since 7.5
(--reflink=auto --sparse=auto).
The ioctl only operates on regular files and symlinks, and always
follows symlinks; checks have been added accordingly.
This patch would be very useful for everyone who uses btrfs
filesystems (Meego folks for instance). On systems that don't have
btrfs, or if the the source is not on a btrfs filesystem, the ioctl
returns EINVAL, and the fallback code is triggered. Hence this will
cause no problems for non-btrfs users.
https://bugzilla.gnome.org/show_bug.cgi?id=626497
In configure.ac, escaping '#' in NAMESER_COMPAT_INCLUDE results in the following gio/gnetworking.h, which obviously doesn't compile:
#include <arpa/inet.h>
#include <arpa/nameser.h>
\#include <arpa/nameser_compat.h>
https://bugzilla.gnome.org/show_bug.cgi?id=690346
Add g_socket_get_option() and g_socket_set_option(), wrapping
getsockopt/setsockopt for the case of integer-valued options. Update
code to use these instead of the underlying calls.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
The gobject tools (glib-genmarshal and gobject-query) were linking
against libgthread. Stop that.
Also, remove the gthread_INCLUDES internal automake substitution.
Using "int main (int argc, char** argv)" in this test causes GCC to
issue two warnings about unused variable if CFLAGS envvar has
-Wunused-parameter (or just -Wextra). Those warnings are not related
to the attribute checking but they can make the test fail anyway.
As the project file format for Visual Studio 2012 is only slightly
different from Visual Studio 2010 projects, we can provide support for
building GLib (and other projects) with Visual Studio 2012 with relatively
little effort. This might change when we eventually get GLib to work with
the Windows 8 (Modern UI/formerly Metro) APIs, but this will suffice for
the time being for people needing to build GLib with Visual Studio 2012.
Basically all that needs to be done at 'make dist' is:
-Copy the .sln/.props/README.txt/.vcxproj files and replace the VS2010
stuff with VS2012 stuff
-Copy the .vcxproj.filters as is
Rather than defining _WIN32_WINNT only in a handful of files, define
it in config.h, like we do with _GNU_SOURCE.
(Also remove a "#define WIN32_LEAN_AND_MEAN" that isn't really all
that useful.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Written by Dmitry Matveev as part of GSoC 2011:
http://netbsd-soc.sourceforge.net/projects/kqueue4gio/
This brings native file monitoring support on systems supporting kqueue(3)
(all BSDs) and remove the need to rely on the unmaintained gamin software.
The backend adds GKqueueDirectoryMonitor and GKqueueFileMonitor.
Some parts rewritten by myself (to prevent needing a configuration file).
Helpful inputs from Colin Walters and Simon McVittie.
https://bugzilla.gnome.org/show_bug.cgi?id=679793
This avoids collecting the zombie child, which means that the PID
can't be reused. This prevents possible race conditions that might
occur were one to send e.g. SIGTERM to a child.
This race condition has always existed due to the way we called
waitpid() for the app, but the window was widened when we moved the
waitpid() calls into a separate thread.
If waitid() isn't available, we return NULL, and consumers of this
private API (namely, GSubprocess) will need to handle that.
https://bugzilla.gnome.org/show_bug.cgi?id=672102
We're not going to depend on gnome-common (I assume) so this patch
nicks the systemd macro to test for compiler flags, and uses it to set
a similar set of -Werror=foo as the gnome-common one does.
See https://bugzilla.gnome.org/show_bug.cgi?id=608953
See https://mail.gnome.org/archives/desktop-devel-list/2012-July/msg00100.html
If we're going to be setting more strict compiler flags for GNOME, we
should really ensure GLib builds with them first, as it's kind of the
model citizen.
In particular, you can see several times that downstreams such as
Debian have come in and fixed -Wformat-security bugs. We should never
let those get into tarballs, or even commits.
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Some programs attempt to use libglib (or even libgio) when setuid.
For a long time, GTK+ simply aborted if launched in this
configuration, but we never had a real policy for GLib.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
This patch adds a private function g_check_setuid() which is used to
first ensure we don't run an external dbus-launch binary if
DBUS_SESSION_BUS_ADDRESS isn't set.
Second, we also ensure the local VFS is used in this case. The
gdaemonvfs extension point will end up talking to the session bus
which is typically undesirable in a setuid context.
Implementing g_check_setuid() is interesting - whether or not we're
running in a privilege-escalated path is operating system specific.
Note that GTK+'s code to check euid versus uid worked historically on
Unix, more modern systems have filesystem capabilities and SELinux
domain transitions, neither of which are captured by the uid
comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-By: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
Solaris/OpenSolaris/OpenIndiana define FIONREAD in sys/filio.h.
This commit adds a configure check for this header, and includes
it conditionally in gio/gsocket.c.
Patch by Fabian Groffen, bug 675524.
Default to generate man pages if the required tools and
stylesheets are found. Error out if --enable-man is given
but tools or stylesheets are missing.
The "-framework" linker flag takes a second word as a parameter. If
they are passed separated with whitespace, some flag-handling routines
may not know to keep the two words together as a single unit. Use
-Wl,, to pass multiple words without embedded whitespace.
https://bugzilla.gnome.org/show_bug.cgi?id=566994
Not doing so is an evil trap, sadly. This patch has been
compile-checked on Fedora 16, and I've verified that the generated
config.status and config.h is exactly the same.
https://bugzilla.gnome.org/show_bug.cgi?id=674483
This way any prerequisites for e.g. AC_CHECK_HEADER are always executed
before the 'if'.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=674483
If action-if-found is not specified, AC_CHECK_LIB will append the library
to LIBS. As we don't want to link everything against libelf, reset LIBS
after doing the checks.
When cross-compiling with gcc >= 4.5 AC_CHECK_ALIGNOF fails to detect the
correct alignment. Without a previous AC_CHECK_TYPE for the same type, the
alignment is silently set to '0'.
This makes sure that configure fails and reports the problem.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=674483
These binaries are now only used by the test suite. glib-genmarshal
*used* to be required to generate marshallers, but isn't anymore now
that we use libffi (via g_cclosure_marshal_generic).
https://bugzilla.gnome.org/show_bug.cgi?id=667806
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
This is needed because glib-mkenums doesn't handle #ifdef values in
enums, and so it needs to have all values always defined in the enum.
When not available, define the missing values to a negative value.
It seems that there is quite a bit of variation out there, in
terms of libelf versions and API. Make the checks more thorough,
by not only checking for elf_begin, but also some of the shdr function
that we need. Also, explicitly check for libelf.h.
This should address bug 673132 and 673253.
On some systems gelf.h may not be stored under the top level include
directory in which case we need to add the correct include paths in
cflags by using pkg-config(1).
When inserting custom code to AC_CHECK_ALIGNOF, make sure to not replace
the default includes, but instead append to them.
This fixes ALIGNOF_GUINT32 and ALIGNOF_GUINT64 that were both 0 when cross
compiling. The third 'unsigned long' test wasn't affected because the
AC_CHECK_ALIGNOF call didn't specify the optional 2nd parameter.
We need a stable sort, and we might as well always use it rather
than have multiple sort versions. This picks up the glibc
merge sort implementation which it uses by default for qsort,
except we don't fall back to non-stable quicksort in some cases
like glibc
https://bugzilla.gnome.org/show_bug.cgi?id=672095
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
This lets you poke at resources in elf files and
standalone resource bundles. So far, only listing
and extracting resources is supported. The support
for elf files requires libelf.
In non-UTF-8 locales, the translations and nl_langinfo() return values
must be converted to UTF-8 before being returned to the caller.
Likewise, when making a recursive call to expand a format like '%x',
the format string must first be converted to UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=668250
This should help getting static builds working on mingw.
Based on a patch by Volker Grabsch, bug 619126.
At the same time, drop the unnecessary GLIB_RT_LIBS variable;
we are already adding -lrt to G_THREAD_LIBS.
If we don't do the cast to the proper size in 32 bits, things like below
doesn't work:
uint8_t u = 20;
void *p;
p = GUINT_TO_POINTER(u);
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=661546
Add GNetworkMonitor and its associated extension point, provide a base
implementation that always claims the network is available, and a
netlink-based implementation built on top of that that actually tracks
the network state.
https://bugzilla.gnome.org/show_bug.cgi?id=620932
For some reason, the setting of g_atomic_lock_free wasn't making it down
to the lower part of the configure script where glibconfig.h was being
generated when building using mingw32-configure.
If we prefix glib_cv_ to the start of the variable name (like everyone
else is doing) then it magically starts working.
I love you, automake.
We clean up the detection of if we should do 'real' atomic operations or
mutex-emulated ones with the introduction of a new (public) macro:
G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to
be done in hardware.
We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our
compiler supports GCC-style atomic operations from the gatomic.h header
because we might be building a program against GLib using a different
set of compiler options (or a different compiler) than was used to build
GLib itself.
Unfortunately, this macro is not available on clang, so it has currently
regressed to using the mutex emulation. A bug about that has been
opened here:
http://llvm.org/bugs/show_bug.cgi?id=11174
These were meant to provide the ability to use GLib directly out of its
build tree but have a couple of rather serious limitations that prevent
their serious use:
- these files only worked with programs built using libtool
- for non-trivial uses, other environment variables will need to be
setup to allow GLib to function properly
- the system doesn't stack well when attempting to use multiple
libraries all uninstalled
The jhbuild --prefix= style system works much better in every way, so we
remove this old hack.
We can just assume that strerror/strsignal are available
nowadays. At the same time, drop use of thread-private storage.
Instead, always return interned strings.
https://bugzilla.gnome.org/show_bug.cgi?id=660849
Now that GMutex is exposed we can avoid the dance we did in ./configure
to allocate the correct amount of space for it within the GStaticMutex.
Remove the checks and move the definitions to gthread.h, trying very
hard to keep ABI-stable (even though we will be deprecating this soon).
Implement g_ascii_strto{d,ll,ull} and g_ascii_formatd using
xlocale functions where available. This is slightly faster
and a lot less icky than our homegrown code.
https://bugzilla.gnome.org/show_bug.cgi?id=640293
configure.ac defined G_THREAD_SOURCE and gthread-impl would #include it.
Instead, since we only have two thread implementations now, and since we
always use the Windows one only on Windows, move the logic to the
Makefile, predicated on 'if OS_WIN32'. Then have the chosen backend do
the #include "gthread-impl.c" from there.
Remove the G_THREAD_SOURCE define from configure.ac.
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
