We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Remove workarounds for NeXTStep (last released in 1995), SunOS (1994),
HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX
4.x (1999), and AIX 4.x (1999).
HP-UX 11 implements dlopen(), so dropping support for earlier versions
also lets us remove the HP-UX-specific gmodule-dld.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.
Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.
So, kill G_OS_BEOS.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
To avoid -Wmissing-prototype warnings, we need to prototype both the
original and the _utf8 versions of all of the functions that have had
_utf8-renaming on Windows. But duplicating all the prototypes is ugly,
so rather than doing them "in-place", move them all to a new header
file just for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
This is a minimal patch-out of the galias functionality. We will do a
release like this so that we can easily back it out if there are
reported problems.
A more substantial cleanup (mostly removing #includes from every file)
will follow if there are no issues.
