This call was needed once upon a time, when GResolver had subclasses
that presumably relied on this. Nowadays, we have only
GThreadedResolver, which does not need it. res_init() is dangerous
because it modifies global state, so let's get rid of it.
The "recursive:" kwarg is available in the targeted minimum version of
meson, and is basically required if you want to not emit warnings and
maybe error with --fatal-meson-warnings.
There are two basic solutions to this problem:
- The current default behavior is false, so explicitly opt in to that
value. None of these internal libraries use recursive objects anyway.
- Use link_with to link to the static library directly, rather than the
extracted objects.
Option 2 is what used to be done before commit
62af03bda8, but it only works with meson
>=0.52 and previously had buggy behavior.
Since the minimum version of meson is now 0.52, it is safe to revert
that commit and go back to using link_with, and therefore option 2 is
chosen.
The variable `gconstructor_code` (which is what’s defined by
`gconstructor_as_data_h`) is not used at all inside
`glib-compile-schemas`.
This looks like a copy/paste error from the build definition for
`glib-compile-resources` below, which does need it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This will require distributions to ensure they pass
`--localstatedir=/var` correctly to Meson, but they should be doing that
already.
See https://mesonbuild.com/Builtin-options.html#directories for details
about how Meson treats `localstatedir` differently from most other `dir`
variables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
With bash completion version lesser than 2.10, only prefix is defined
while for greater version it is datadir.
Closes#1054
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
This is a COM object that implements IStream by using a HANDLE
and WinAPI file functions to access the file (only a file; pipes
are not supported). Only supports synchronous access (this is
a feature - the APIs that read from this stream internally will
never return the COM equivalent of EWOULDBLOCK, which greatly
simplifies their use).
This command will try to execute a desktop file, before that
it will load the input as a keyfile for checking its existence
and its validity (as a keyfile).
File arguments are allowed after the desktop file.
Closes#54
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Meson 0.54.0 added a new method meson.override_dependency() that must be
used to ensure dependency consistency. This patch ensures a project that
depends on glib will never link to a mix of system and subproject
libraries. It would happen in such cases:
The system has glib 2.40 installed, and a project does:
dependency('glib-2.0', version: '>=2.60',
fallback: ['glib', 'glib_dep'])
dependency('gobject-2.0')
The first call will configure glib subproject because the system libglib
is too old, but the 2nd call will return system libgobject.
By overriding 'gobject-2.0' dependency while configuring glib subproject
during the first call, meson knows that on the 2nd call it must return
the subproject dependency instead of system dependency.
This also has the nice side effect that with Meson >0.54.0 an
application depending on glib can declare the fallback without knowing
the dependency variable name: dependency('glib-2.0', fallback: 'glib').
There were some problems about where to install `gio-launch-desktop` to
support multiarch systems without circular dependencies. Simon McVittie
suggested that, actually, given the current set of platforms supported
by `GDesktopAppInfo` (they’re all POSIX), we could just use `sh`.
That simplifies things nicely. `gio-launch-desktop` can always be
resurrected (and the multiarch debate continued and resolved) if needed
in future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1633
There were a couple of custom paths which could end up being relative,
rather than absolute, due to not properly prefixing them with
`get_option('prefix')`.
The use of `join_paths()` here correctly drops all path components
before the final absolute path in the list of arguments. So if someone
configures GLib with an absolute path for `gio_module_dir`, that will be
used unprefixed; but if someone configures with a relative path, it will
be prefixed by `get_option('prefix)`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1919
If we're cross-compiling, the installed-tests are useful even if we
can't run them on the build machine: we can copy them to the host
machine (possibly via a distro package like Debian's libglib2.0-tests)
and run them there.
While I'm changing the build-tests condition anyway, deduplicate it.
Based on a patch by Helmut Grohne.
Bug-Debian: https://bugs.debian.org/941509
Signed-off-by: Simon McVittie <smcv@collabora.com>
The header file was installed when building using autotools, but was
inadvertently omitted in the meson targets.
Luckily, ABI is not impacted, since gnativesocketaddress.c was always
compiled and linked into libgio.
Fixes: #1854
This fix build error for projects that use gnome.compile_resources()
when glib is built as a subproject and not installed on the build
machine.
Note that this is not working for cross compilation cases, because it
would require to compile everything twice (for host and build machines).
A better solution would be to rewrite those tools in python. See #1859.
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.
While we can't fix the kernel unwinding here, we can provide proper
c_marshallers and va_marshallers for objects within Gio so that
performance profiling of applications is more reliable.
Related to GNOME/Initiatives#10
The most useful ones were already listed in the pkg-config file, but
some others (notably, `gio-querymodules`) were not. List them in the
pkg-config file with their installed paths so that the right binary is
used if GIO is installed in a non-default path.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1796
Currently, there is no way to prevent tests from building using meson.
When cross-compiling, building the tests isn't necessary.
Instead, only build the tests on the following conditions:
1) If not cross-compiling.
2) If cross-compiling, and there is an exe wrapper.
Almost everything that needs gioenumtypes.h also needs
gobjectenumtypes.h. Fixes:
ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
In file included from ../gio/win32/gwin32filemonitor.h:25:0,
from ../gio/win32/gwin32filemonitor.c:26:
../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
#include <gobject/gobjectenumtypes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
1) Remove the non-Windows-only condition for subdir('tests').
2) Add libiphlpapi, libws2_32 and libsecur32 deps, needed for W32 tests.
3) Remove the -no-undefined argument (gcc doesn't understand it,
it *does* understand -Wl,-no-undefined; either way, the test
compiles without this argument just fine; maybe meson adds it
by itself - you can hardly build shared modules without it).
4) Add or fix a number of includes
5) Disable gdbus-objectmanager tests when building with MSVC
(right now these tests don't work on Windows anyway, so the fact
that MSVC can't even build them properly is irrelevant;
most likely gdbus-codegen needs changes to put _GLIB_EXTERN
before each function)
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
7efd76dd67 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
In order to use the new posix_spawn gspawn codepath, for more robust
app launching when available memory is low, we need to meet some
conditions.
child_setup needs to be NULL for this optimization to work, so drop
the internal child_setup that is used here. Replace it with a lightweight
wrapper binary (gio-launch-desktop) that sets GIO_LAUNCHED_DESKTOP_FILE_PID
before executing the app.
Adjust PATH for gio tests so that it can execute the new binary from the
build directory.
GVfs utils used to have bash completion, which was pretty useful. However,
it hasn't been ported to gio tool unfortunately. GLib provides completion
for various utils already, so it would be nice to provide completion also
for gio tool. I've updated old bash completion code and merged with some
my old unmerged fixes.
The gvfs completion used "gvfs-ls --show-completions" helper. This mentioned
option hasn't been obviously ported to "gio list" and the proposed completion
doesn't add this option in "gio list" to not pollute the codes, but maybe it
is a bit slower as consequence.
The proposed bash completion suggests subcommands, uris and paths including
the remote mounts. It contains some workarounds, especially because of proper
handling of paths with colons and other special chars (like spaces)...
libelf, just like libc, is not a single project. It is an interface
which can be implemented independently by different operating systems.
Therefore, we cannot expect all systems to provide a .pc file, and we
should fallback to cc.find_library and cc.has_function like what we
already do in autotools build.
gio-querymodules-wrapper.py is copied from glib-networking. This python
wrapper script is needed because meson.build cannot check for DESTDIR
env variable itself, unlike Makefile.am. It is used to update
giomodule.cache file when installing GIO modules like fam.
- Compiler checks were failing because it were using C compiler to build
objc code.
- xdgmime is needed on osx too.
- -DGIO_COMPILATION must be passed to objc compiler too.
- gapplication doesn't build on osx, it is excluded in autotools too.
We have to be careful when we use add_project_link_arguments(): All
targets are built using link arguments for the C language, except for
libgio on osx which use the objc language, because it contains some ".m"
source files. See https://github.com/mesonbuild/meson/issues/3585.
https://bugzilla.gnome.org/show_bug.cgi?id=796214
Those files got renamed to .c to work around an automake issue, but
Meson needs them to have .m extension. Better rename them at build time
in Makefile.am since that's where the workaround is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=672777
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
This adds a null notification backend implementation for win32, purely
to avoid crashes due to a missing backend when applications use
GNotification. This backend does nothing except print a warning when a
notification is supposed to be emitted.
In future, it can be expanded to use win32 API to present toaster
notifications appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776583
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
This makes it more consistent with the other win32 objects in GIO. This
commit just renames the files; a follow-up commit will rename the
GObject.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=685442
Added a Windows backend to GNetworkMonitor, using NotifyRouteChange2()
(available on Vista and later). It marshals the route change callbacks
to the thread-specific default main context the GNetworkMonitor was
constructed in.
https://bugzilla.gnome.org/show_bug.cgi?id=685442
Properly define GLIB/GOBJECT_STATIC_COMPILATION when static build is enabled.
Use library() instead of shared_library() to allow selecting static builds.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
GIO modules should include their name into their exported symbols to
make them unique. This avoids symbol clash when building modules
statically.
extract_name() function is copied from GStreamer which recently
switched to the same symbol naming scheme.
https://bugzilla.gnome.org/show_bug.cgi?id=684282
In autotools this same check reads:
AS_IF([test $glib_native_android != yes]
with glib_native_android being defined as:
case $host in
*android*)
glib_native_android="yes"
;;
*)
glib_native_android="no"
;;
esac
This is needed to be able to compile on OSX.
https://bugzilla.gnome.org/show_bug.cgi?id=791460
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
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
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
We want to set _WIN32_WINNT so that functions will be properly found in
the headers, to target the NT6.1+ (Windows 7+) APIs.
Also improve the checks for if_nametoindex() and if_indextoname() on
Windows as they are supported in Windows Vista+, but they have
to be checked by linking against iphlpapi.lib (or -liphlpapi). On other
platforms, they are still checked as they were before.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
When building glib as a subproject, #include's for xdp-dbus.h from xdp-dbus.c
and for gdbus-daemon-generated.h from gdbus-daemon-generated.c were generated as
being prefixed with the subproject prefix, eg
#include "subproject/glib/gio/gdbus-daemon-generated.h".
That failed since the root of the build directory is obviously not part of the
include path when building a subproject.
Passing --output-directory @OUTDIR@ to gdbus-codegen and removing @OUTDIR@ from
--generate-c-code fixes the issue.
meson.source_root() returns the toplevel source directory
of the toplevel project, thus the paths were wrong when using
it. Simply using files() gets us the right path
https://bugzilla.gnome.org/show_bug.cgi?id=784133
Need to fix up some of the tests a little, because the
test binary will not necessarily be run from the current
build sub-directory, and the build directory structure
might not always be a mirror of the source directory
structure, so pass location of glib-mkenums and
glib-compile-scheme and such directly.
This reduces the build-time dependencies of glib to only Python 3,
Meson, and git. Git is also optional if you provide a tarball in
which the subproject directories already exist.
The Python port was done by Jussi Pakkanen on bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This version contains some fixes from that and also changes all
instances of `@` to `\u0040` because Meson does not yet provide a
configure_file() mode that ignores unknown @MACRO@ values.
This is a stub-only library that can be used while building against
MSVC and contains no i18n machinery at all.
The dependencies added indirectly use the libintl.h header, and when
built as a subproject, the header won't be in a path known the
pre-processor.
Don't use it project-wide for building everything. Otherwise
symbols for shared modules won't be exposed, e.g. in the
resourceplugin used by the gio resource unit test.
