On an Android build, API 22, at least, I got a:
> warning: "UNIX_PATH_MAX" redefined
We were currently defining it as:
> #define UNIX_PATH_MAX sizeof (((struct sockaddr_un *) 0)->sun_path)
Whereas Android's headers define this variable of sockaddr_un as:
> char sun_path[UNIX_PATH_MAX];
So by definition, we will still get the right result in the end by just
using the original value of UNIX_PATH_MAX.
C_IN macro was added years ago in bcbaf1bef0, using same value as the
internal code of Android with the reasonning that "some parts of the API
used by the resolver objects is not public in the Android NDK (yet)".
Well since then things are changed, since it is definitely available (at
least on the API 22 of Android which I am using) in the public header
arpa/nameser_compat.h.
Let's just add a #ifndef to handle both cases when you build with an
older or recent API.
Make the --help output more consistent with the man page, making it more
obvious that --sourcedir only applies to the files referenced in FILE,
not to the location of FILE itself.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1406
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.
The previously implementation considered a file to be a mountpoint if
its parent is on a different device. / is its own parent, so by this
definition it is not a mountpoint.
But / is (generally) listed in fstab, and fstab(5) defines the
directories it contains to be mountpoints. This attribute should follow
that definition (and reasonable expectation): the root directory is a
mountpoint.
So, add a special-case for the case where the file's parent has the same
st_dev and st_ino as the file, which is true only at the root.
Test this attribute at / (only on POSIX), /proc (but only on Linux), and
at many files and directories created by the test suite (which cannot be
mountpoints).
The test 'file' uses non-standard '--bytes' option when running du,
which may cause error on non-GNU systems. To keep the test working,
we skips the du check as if we don't find a du command when du fails.
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.
Change G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH logic to be consistent
with recent g_local_file_trash changes, i.e. set this to FALSE for
locations on system-internal mounts.
https://gitlab.gnome.org/GNOME/glib/issues/251
New bugs appears periodically in nautilus/gvfs/glib components that not
all trashed files are shown in trash:///. It used to be problem mostly
for "bind mounts" and btrfs subvolumes only. Currently, it is also
problem for nfs, cifs and other filesystems, which have been recently
added by commmit 0d69462f on the list of system internal filesystems.
This happens because the trash backend doesn't monitor files on system
internal mounts. Such behavior is not against the trash-spec, however,
we should be consistent within GNOME.
This behavior has the nice side-effect that it solves issues with hangs
on network filesystems: https://gitlab.gnome.org/GNOME/glib/issues/605,
because those are currently on the system internal filesystem list.
https://gitlab.gnome.org/GNOME/glib/issues/251
This test assumes the subprocess does not print anything else on stdout
other than the dbus address, otherwise g_test_trap_assert_stdout()
fails to match. But if the env running tests has G_MESSAGES_DEBUG=all
then it will also print "PATH=%s".
It's a synonym of G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE.
It doesn't change anything except not feeling dirty from using a wrongly
prefixed constant for the object type.
See: #182
Help is usually printed from tools if no arguments are given and there
is not default action. However "gio mount" and "gio trash" just silently
return. Let's print "No locations given" error and show help consistently.
"gio help COMMAND" shows some arguments with "..." and some with "…",
which looks weird, e.g.:
$ gio help mount
gio mount [OPTION…] [LOCATION...]
Let's use "…" consitently.
- 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
Fixes this build error on macOS when inside an ssh terminal:
Traceback (most recent call last):
File "[...]/gio/tests/gengiotypefuncs.py", line 23, in <module>
for line in f:
File "[...]/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2625: ordinal not in range(128)
https://bugzilla.gnome.org/show_bug.cgi?id=796328
GVfsUDisks2VolumeMonitor handles x-gvfs-hide/x-gvfs-show mount options
used to overwrite our heuristics whether the mount should be shown, or
hidden. Unfortunately, it works currently only for mounts with
corresponding fstab entries, because the options are read over
g_unix_mount_point_get_options. Let's introduce g_unix_mount_get_options
to allow reading of the options for all sort of mounts (e.g. created
over pam_mount, or manually mounted).
(Minor fixes to the documentation by Philip Withnall
<withnall@endlessm.com>.)
https://bugzilla.gnome.org/show_bug.cgi?id=668132
