This was inadvertently changed when the numeric enum value subs were
introduced.

By using bitwise instead of integer arithmetic.

Install, for example, a constant sub Glib::IOCondition::HUP returning
the number 16.

This is useful when a function, signal or property expects or returns an
enum or flags value, but the API specification is such that our special
enum and flags string handlers are not invoked.  Example:
Gtk3::TextTag's "weight" property accepts any positive integer but
predefined values are given by the Pango::Weight enum.

GVariantParseError was introduced in glib 2.28, a bit later than
GVariant.

Should fix compilation of dependent modules like Glib::Object::Introspection.

Wrapping the majority of the GVariant and GVariantType API.

These use SvPVbyte to ensure that the bytes that the user stored in the string
are passed on, regardless of which internal representation perl happens to use.

Glib's child watches will not work when perl was not linked with "-pthread".

https://rt.cpan.org/Ticket/Display.html?id=82349

On OpenBSD, any program that directly or indirectly wants to load libpthread.so
must do so from the start.  But when perl is built without ithreads, it will
also most likely not be compiled with "-pthread".  When libglib/libgobject then
go and try to load libpthread.so, the loader will error out.

Fix by setting LD_PRELOAD=libpthread.so at the relevant points in the build and
test process.

There have been no reports of breakage due to this mechanism.  But there have
been requests to disable the warning.  Comply.

https://rt.cpan.org/Ticket/Display.html?id=91313

Emmanuele Bassi authored Nov 11, 2013 and Torsten Schönfeld committed Dec 08, 2013

We want to keep the ability to build perl-Glib with ancient versions of
GLib, but we also want to avoid compiler warnings when compiling against
modern versions of GLib. This means avoiding deprecated API, and trying
to keep up with the development of the library as much as possible.

https://bugzilla.gnome.org/show_bug.cgi?id=711840

This reverts the commit "Ensure timely destruction of initial wrapper of custom
subclasses", eb6ff1b1.

It turns out that the change causes issues with subclasses inheriting from
GInitiallyUnowned.  Instances of classes derived from GInitiallyUnowned would
be destroyed prematurely when code in INIT_INSTANCE manages to sink the
initial, floating reference.

Reported by Kevin Ryde.

t/7.t was failing on perl 5.19.4 because it attempted to assign to undef.

Needed for libvte.

In preparation for the upcoming changes.