2008-02-22 Mark Doffman <mark.doffman@codethink.co.uk>
* tools/quote-file.sh
* tools/compiler.c
* tools/generate.c
Move to using the 'C' struct compiler code.
WARNING: This commit does not compile. It is a partial change.
svn path=/trunk/; revision=135
* src/compiler.c, src/generate.c, src/gidlnode.c,
src/gidlparser.c, src/ginfo.c, src/girepository.c,
tests/invoke/invoke.c, test/invoke/testfns.c: Hush compiler
warnings about return values, signedness mismatches, unused
variables, and unhandles enum values in switch statements.
* tests/invoke/Makefile.am: Don't install the invoke test program.
Add -I ../../src to the cflags used for the test functions files.
2005-05-24 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (main): Use it here to validate
the generated metadata.
* src/gmetadata.[hc]: Add code to validate a
metadata blob.
2005-05-13 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (format_output): Make the generated
C code compile.
* README: Point to a recent libffi snapshot.
* tests/invoke/*: Some invoke tests.
* src/Makefile: Add ginvoke.c and the necessary
libffi information.
* src/girepository.h (g_function_info_invoke): Add
a GError argument.
* src/ginvoke.c (g_function_info_invoke): Initial
implementation of invoke functionality based on libffi.
2005-05-11 Matthias Clasen <mclasen@redhat.com>
* src/compiler.c (main): Add a --verbose cmdline option
and only log messages if it is specified.
* src/gidlnode.h:
* src/gidlnode.c (init_stats, dump_stats): Collect some
statistics on string and type sharing.
* src/gidlmodule.c (g_idl_module_build_metadata): Use
g_message() instead of fprintf().
* src/gidlnode.c (g_idl_node_free): Make this more robust.
(g_idl_node_get_size): Implement for structs.
(g_idl_node_get_full_size): Handle parent being NULL.
(serialize_type): Handle lookup failures more gracefully.
2005-05-10 Matthias Clasen <mclasen@redhat.com>
* src/gidlnode.c (g_idl_node_get_full_size): Correct the
size calculation for 2-parameter types and for objects.
* src/compiler.c: Add a cmdline option for debug output
and install a log handler to implement it.
* src/gidlnode.c: Add some debug spew.
GType is either an integer or a pointer, so we have to use the _pointer
version here to support architectures such as Morello.
These two lines were missed in 5ecd3cbe52
and allows the gobject/enums test to pass on CheriBSD (Morello).
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
This also fixes the build for AArch64 since cmph_uint32 is not big
enough to hold a pointer there. I found this while building for CHERI
since the compiler errors there when casting from a non-inptr_t integer.
This also fixes warnings when building for AArch64 with clang.
This doesn't appear to work reliably on s390x and ppc64, returning
the results that were expected without %E or intermittently crashing.
It seems that on little-endian 64-bit, the intptr_t returned by the
undocumented _NL_TIME_ERA_NUM_ENTRIES correctly has the number of entries
in its low-order half (at the time of writing, 0x0000'0000'0000'000b for
Japan), but on big-endian 64-bit, it has the number of entries in its
high-order half instead (for example 0x0000'000b'0000'0000 for Japan),
with the low-order half being all-zero or possibly uninitialized.
Making this reliable will require some sort of defined API from glibc.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Bug-Debian: https://bugs.debian.org/1060735
Signed-off-by: Simon McVittie <smcv@collabora.com>
As seen in [CI](https://gitlab.gnome.org/GNOME/glib/-/jobs/3436216):
```
==13767== 144 (40 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 528 of 562
==13767== at 0x4A18B2C: g_type_create_instance (gtype.c:1928)
==13767== by 0x49F92FF: g_object_new_internal (gobject.c:2235)
==13767== by 0x49FA247: g_object_new_valist (gobject.c:2574)
==13767== by 0x49F8D81: g_object_new (gobject.c:2047)
==13767== by 0x4AE2337: g_inet_socket_address_new (ginetsocketaddress.c:387)
==13767== by 0x4B1DB94: g_socket_address_new_from_native (gsocketaddress.c:230)
==13767== by 0x4B16CC2: g_socket_get_local_address (gsocket.c:2071)
==13767== by 0x40E102: test_receive_bytes_from (socket.c:2469)
==13767== by 0x4901E78: test_case_run (gtestutils.c:2974)
==13767== by 0x49022B2: g_test_run_suite_internal (gtestutils.c:3069)
==13767== by 0x490241A: g_test_run_suite_internal (gtestutils.c:3088)
==13767== by 0x4902690: g_test_run_suite (gtestutils.c:3168)
==13767== by 0x4900C8F: g_test_run (gtestutils.c:2275)
==13767== by 0x40EE8A: main (socket.c:2614)
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3220
We only care about the introspection data for documentation purposes;
the GStaticMutex and GStaticRecMutex types are long since deprecated,
and they cannot be used from language bindings anyway, so their size is
immaterial.
Fixes: #3222
There are several reasons why we might not be able to do the test setup
for --external-data: non-Linux platform, missing ld or objcopy,
objcopy doesn't support --add-symbol, or the CPU family is MIPS
(on which cc -r does not necessarily emit the specific MIPS ABI flavour
that we are targeting, for example different functionality levels or
different NaN encodings).
If we can't link in the test data, then obviously this test is not going
to pass. It was already skipped on non-Linux, but not on platforms that
hit one of the other reasons for the test setup to fail.
In particular, this test failed on Debian mips64el since commit 81059169,
which stopped linking the necessary resource on MIPS platforms, but
continued to assert that the resource is present at runtime.
Fixes: 81059169 "GIO/tests: skip test_resources_binary on MIPS platform"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3226
Signed-off-by: Simon McVittie <smcv@debian.org>
Now that the reference documentation uses gi-docgen, it's more
troublesome to generate in less standard build scenarios like
cross-compiling.
In distributions like Debian, reference documentation is generally
packaged separately (in libglib2.0-doc in Debian's case), but man pages
are generally packaged alongside the executables themselves (in the
libglib2.0-bin and libglib2.0-dev-bin packages, in Debian's case). We
can exclude the reference documentation when cross-compiling, but ideally
we would like the man pages to still be built, so that a cross-compiled
libglib2.0-bin or libglib2.0-dev-bin package has the same content as a
native build.
Signed-off-by: Simon McVittie <smcv@debian.org>
