On Visual Studio, Meson builds modules as xxxx.dll, not libxxxx.dll when
xxxx is specified as the name for the shared_module() build directive.
This means that in the test programs if we expect for libxxxx for the
module name, the test will fail as there is no libxxxx.dll but there is
xxxx.dll. This makes the test program look for the module files
correctly.
[23/236] Compiling C object 'lib/76b5a...isc@sha/contrib_gvdb_gvdb-reader.c.o'.
../../../../Projects/epiphany/lib/contrib/gvdb/gvdb-reader.c: In function ‘gvdb_table_get_names’:
../../../../Projects/epiphany/lib/contrib/gvdb/gvdb-reader.c:428:27: warning: comparison of integer expressions of different signedness: ‘guint32’ {aka ‘unsigned int’} and ‘gint’ {aka ‘int’} [-Wsign-compare]
428 | else if (parent < n_names && names[parent] != NULL)
| ^
To fix this, we have to change n_names to guint, and then also change
the types of everything it's compared against. This seems to be safe
since none of these should ever be negative.
It's confused both myself and Jan-Michael, when reviewing my changes to
this code. It's weird for the serialize function to take ownership of
the passed FileBuilder. Don't do that.
We can also add a convenience free function.
I'm not auditing all the public functions in this file for precondition
checks, but since I'm adding an async version of this function, it
makes sense to ensure there are matching checks for the sync version.
This is just an async version of gvdb_table_write_contents().
Future work: someone could write an async version of gvdb_table_new(),
then sync I/O would no longer be required to construct a GvdbTable.
We are still seeing occasional CI failures due to timeouts when heavily
loaded. It’s best to wait a little longer than to throw all the results
out when they’re almost done.
For example, see https://gitlab.gnome.org/tristan957/glib/-/jobs/331330.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The g_creat() call was done in *nix style in regards to the mode parameter,
which the Windows CRT isn't going to understand (nor like, on newer CRTs).
Update the program such that it will pass, by using Windows-style
permission mode parameters for g_creat(), on Windows.
On Windows, everything is assumed as UTF-8 in g_get_filename_charsets(),
so setting G_FILENAME_ENCODING envvar has no effect, so we can just skip
the test on g_get_filename_charsets() where we try to influence it by
setting the G_FILENAME_ENCODING envvar.
When building a valist marshaller, we can avoid reffing a GParamSpec
if the argument is known to always be static. The marshaller we ship in
`gmarshal.c` got this right, but marshallers generated by
glib-genmarshal were missing the optimisation. Fix that, and add a unit
test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1792
This makes use of the string we now have from glib-private.h in the
last commit so that setlocale() sets the default system locale
correctly and therefore show the translated messages properly.
Fixes issue #1169.
On Windows, in particular the CRTs on and after Visual Studio 2012, it
is not enough just to do setlocale (LC_ALL, "") to set the default
system locale, which results in the tools that use the translated
messages to show unreadable messages when running the commmand line
tools.
This adds an entry in glib-private.h.in which denotes the appropriate
string to use for setlocale() to set the default system locale by
setting it to ".ACP" if we are building on Windows and "" for
other systems (as we are doing now).
The tools in gio/ will be updated in the next commit to make use of this
entry so that the translated messages can be shown correctly.
From grefcount.h, in order to disable warnings when G_DISABLE_CHECKS is
defined, we need to make use of the GCC-isque-only __extension__ for it
to work. This means that in the saturation tests, we can only expect no
warnings to show if we are building on GCC-isque compilers with
G_DISABLE_CHECKS defined.
This will fix the refcount-macro test on Visual Studio builds at least.
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
If c_marshaller is provided during g_signal_new() registration, the
automatic va_marshaller will not be set. If we leave the c_marshaller as
NULL in the simple cases, both a c_marshaller and va_marshaller will be
set for us.
This is particularly helpful when dealing with stack traces from Linux
perf, which often cannot unwind the stack beyond the ffi_call_unix64
stack-frame on x86_64.
Related to GNOME/Initiatives#10
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.
Related to GNOME/Initiatives#10
If we specify a c_marshaller, g_signal_newv() will never assign an
va_marshaller automatically. So either use NULL (for simple cases), or
specify both to avoid the generic performance penalty.
