While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Use the same code GSocket does, to try SOCK_CLOEXEC first, and then
fall back to FD_CLOEXEC if it fails. (And fix that code to not call
fcntl if SOCK_CLOEXEC worked.)
https://bugzilla.gnome.org/show_bug.cgi?id=692332
When an error occurs while reading the file input stream in
g_file_load_contents (e.g. because the operation was cancelled), the
code is correctly calling g_task_return_error(), but in the callback
from the close operation, g_task_return_boolean() will be called again.
Code that cleans up its state in the async callback will then be called
twice, leading to invalid memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=692202
Declare explicit support for monitor NFS from the fam file monitoring
backend. This will cause it to be preferred for monitoring on NFS, if
it is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Get rid of the complicated default module detection code in
GLocalFileMonitor and GLocalDirectoryMonitor and use the new
_gio_module_get_default_type() function instead.
This change also adds the ability to override the default file monitor
via the GIO_USE_FILE_MONITOR environment variable in the same way as can
be done for GIO_USE_VFS.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
_gio_module_get_default() is a very convenient function for modules
implementing a singleton -- it finds the default module by priority
subject to override by a given environment variable name, instantiates
it, and caches the instance for future calls. It also has the ability
to query instances for being 'active' using a callback.
It doesn't work very well for non-singletons (like file monitors).
Add a new function _gio_module_get_default_type() that skips the
instantiation, returning the GType instead. As a replacement for the
'active' callback, a vtable offset can be given for a virtual function
to use to query if a particular backend is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
Add read_async() and skip_async() tests to buffered-input-stream.
Fix and re-enable filter-streams's existing close_async() tests, and
add read_async(), skip_async(), and write_async() tests as well. Also,
redo the tests to use dummy GFilterInputStream and GFilterOutputStream
subclasses rather than GBufferedInput/OutputStream, so that we're
testing the base filter stream implementations of everything (since
the buffered stream overrides are already getting tested in the
buffered-input-stream and buffered-output-stream tests anyway).
Add a skip_async() test to unix-streams. (This one would crash without
the bugfix in the previous commit.)
skip_callback_wrapper expect the user_data (callback_data)
to be the task holding the task_data, not the task_data
itself.
Otherwise the task_data is cast as GTask and then task_data
is extracted from this bogus task.
https://bugzilla.gnome.org/show_bug.cgi?id=691812
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
Add an #ifdef G_OS_UNIX around the GLIB_AVAILABLE_IN_ALL annotation on
the _get_type() functions for GLocal{File,Directory}Monitor.
These symbols are in private header files and are only exported so that
the in-tree file monitoring modules can subclass. This is only needed
on UNIX and was therefore never part of the public ABI on Windows.
Caught by Dieter Verfaillie.
One of our testcases builds a small giomodule for testing the loading of
modules containing resources. Unfortunately, this module gets built
using the same CFLAGS as the rest of GLib, including the visibility
flags (defaulting to hidden).
Use "config.h" to get a declaration of _GLIB_EXTERN that will export
symbols properly and use it to annotate the necessary APIs.
The kqueue file monitoring backend was misusing G_GNUC_INTERNAL for want
of 'static' in a couple of places and also using it to declare a lock
that was never used at all.
Fix those up.
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
