When updating to libglib2 2.62.0, the file 0002-add-option-to-build-tests.patch
had to be refactored to work with the new build_tests checks. In the process of
refactoring, a missing check was overlooked in glib/meson.build causing
distributions with older versions of objcopy to fail because the older version
does not contain the --add-symbol argument.
Adding the check for the build_tests argument fixes the issue.
Fixes:
http://autobuild.buildroot.net/results/dcc2352a036aba9650eae8abaaa23819fc67332d
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following check-package warning:
package/libglib2/libglib2.mk:90: consecutive empty lines
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libglib2 needs util-linux only for libmount, which is a configuration option.
Instead, check if util-linux-libmount is selected, and if so, set the option
to true.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Other changes:
- Refactor 0002-add-option-to-build-tests.patch to work with the new version.
- Add the new option oss_fuzz=disabled to HOST_LIBGLIB2_CONF_OPTS and
LIBGLIB2_CONF_OPTS.
- Change -Diconv=gnu to -Diconv=external as the option has changed.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Globally change Adam Duskett's email address to aduskett@gmail.com.
Note that one or two of the patches may have been applied upstream with
the old email address, but in that case those patches will anyway be
removed when bumping.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit 4102db0f7 (package/libglib2: bump to version 2.60.3) did convert
libglib2 over to meson. In doing so, it left a very corner-case along.
When the target is an ARM CPU and the build is in thumb mode, then we
want to ensure that libglib2 is still built in arm mode (because of
inline asm).
But with meson, CFLAGS from the environment are passed to the host
compiler, so the build breaks, and the meson log contains:
Appending CFLAGS from environment: '-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -marm'
No LDFLAGS in the environment, not changing global flags.
No CPPFLAGS in the environment, not changing global flags.
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -marm [...]/build/libglib2-2.60.4/build/meson-private/sanitycheckc.c -o [...]/build/libglib2-2.60.4/build/meson-private/sanitycheckc.exe
Sanity check compile stdout:
-----
Sanity check compile stderr:
cc: error: unrecognized command line option ‘-marm’; did you mean ‘-mabm’?
-----
meson.build:1:0: ERROR: Compiler cc can not compile programs.
Fix that by using the new per-package CFLAGS feature of the meson infra.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
libglib2 uses a very crude and error-prone way to detect the intl
functions, which basically fails when the C library is not glibc.
There is a bug report about this in upstream meson [1], but it doesn't
seem to get any progress. Fixing that properly in Buildroot looks
complicated.
Now that a meson package can specify its LDFLAGS, use that to pass the
infrastructure-provided TARGET_NLS_LIBS to link with.
Fixes:
http://autobuild.buildroot.org/results/f0d/f0d85d76786343d767fba9c7c5c01f042ecfc018/
[...]
[1] https://github.com/mesonbuild/meson/issues/3740
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Apply LIBGLIB2_REMOVE_BINDIR_PREFIX_FROM_PC_FILE to gio-2.0.pc so
${bindir} prefix is also removed for gbus-codegen otherwise build of
packages using this binary will fail if gbus-codegen is not installed on
host
Fixes:
- http://autobuild.buildroot.org/results/5c0e4f3d33e01198688d58388aabe159bd005234
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Changes include:
- Change the package type to meson, as autoconf is no longer supported.
- Add 0002-add-option-to-build-tests.patch
Upstream won't build tests when cross-compiling. However; this means still
building the tests during a host build. Building the tests causes build
failures on older distributions such as CentOS 6 and Debian 7 because of
the command `objcopy --add-symbol` is used when building the test
"test_resources2," which is not available with the older version of
objcopy provided by the distributions.
- Add 0003-remove-cpp-requirement.patch:
C++ is not needed when just compiling. The inclusion of C++ in meson.build
is to ensure libglib doesn't accidentally use C++ reserved keywords in
public headers. Because tests aren't being compiled, there is no need for
C++ as a requirement.
(https://gitlab.gnome.org/GNOME/glib/issues/1748)
- Add 0004-Add-Wno-format-nonliteral-to-compiler-arguments.patch:
This prevents a false error when compiling against older gcc versions.
(https://gitlab.gnome.org/GNOME/glib/issues/1744)
- Remove 0004-Do-not-hardcode-python-path-into-various-tools.patch:
The switch to meson makes this obsolete.
- Remove LIBGLIB2_AUTORECONF = YES from libglib2.mk:
Now that libglib2 is a meson package, there is no need for AUTORECONF.
- Remove LIBGLIB2_INSTALL_STAGING_OPTS from libglib2.mk:
Meson resolves these correctly.
- Add LIBGLIB2_REMOVE_BINDIR_PREFIX_FROM_PC_FILE in libglib2.mk:
Newer versions of libglib2 prefix glib-genmarshal, gobject-query, and
glib-mkenums with ${bindir}. Unfortunately, this will resolve to the host
systems /bin/ directory, which will cause compilation issues if the host
does not have these programs. By removing the ${bindir}/ prefix, these
programs are resolved in PATH instead.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
GCC 9 is being stricter about passing null string pointers
to printf-like functions.
Signed-off-by: Grzegorz Blach <grzegorz@blach.pl>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If libselinux is selected, explicitly set --enable-selinux in the
configure options and build the library first.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the switch to pkgconf 1.5.3 in commit
4e42366939, the glib-networking package
has been failing to build with:
glib-networking: installs files in /home/naourr/work/instance-0/output/host/i686-buildroot-linux-uclibc/sysroot//home/naourr/work/instance-0/output
This error is due to glib-networking having installed its GIO GnuTLS
module into an invalid location. This invalid location is
$(DESTDIR)$(GIO_MODULE_DIR). GIO_MODULE_DIR is found by using:
pkg-config --variable giomoduledir gio-2.0
Unfortunately, despite the pkgconf fix in commit
7125fc5c1a ("package/pkgconf: add patch
to restore pre-1.5.3 behavior for sysroot prefixing"), the value
returned by pkg-config for giomoduledir remains prefixed by the
sysroot.
This is due to the fact that giomoduledir is defined by default with
the value ${libdir}/gio/modules. When running pkg-config --variable
giomoduledir gio-2.0 with the new pkg-config version, what happens is
that libdir is resolved first, and libdir is one of the variable for
which we add the sysroot prefix. Then later, giomoduledir is
resolved. For this variable, we don't prefix with the
sysroot. However, when resolving the value of giomoduledir, it re-uses
the value of libdir that was already resolved, and this value includes
the sysroot prefix.
There is no simple way to solve this problem within pkg-config. So for
the time being, we take a simple route: make sure giomoduledir isn't
defined in terms of ${libdir}. This is easily done by passing
--with-gio-module-dir to libglib2 configure script.
Fixes:
http://autobuild.buildroot.net/results/4167159c4a03f5a72dbd7e286aedb3845164cc22/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This reverts commit 178eb1d7ea. This
bump causes too many build failures in reverse dependencies of
libglib2, for which a proper solution needs to be found.
See also the analysis from Yann E. Morin:
http://lists.busybox.net/pipermail/buildroot/2018-December/237663.html
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Update second patch
- Remove third and fifth patches (already in version)
- Add a new patch to fix a missing header
- Add LIBGLIB2_GTK_DOC_HOOK so autoreconf do not fail on the following
error:
automake: error: cannot open < gtk-doc.make: No such file or directory
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On RHEL6 hosts, fcntl.h doesn't define F_SETPIPE_SZ or
F_GETPIPE_SZ. Upstream glib has a patch for this case that wasn't
applied to their 2.56.1 branch.
Fixes:
http://autobuild.buildroot.net/results/04b98a0b5c593c0525ef39d03c1ee7c2bbf5e44d/
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When the output directory is nested under a long path name, calling the
gdbus-codegen, glib-genmarshal, or glib-mkenums scripts throws the
error:
> '/usr/bin/env: /...: No such file or directory'
This is because libglib2 uses the absolute path to the python
interpreter for its shebang statements, and shebangs have a max length
of 127 chars[1]. A long absolute path will be cut off and appear as a
missing file.
Since the host Python is present in the $PATH passed to all packages, we
can copy the workaround from Yocto and just use the python interpreter
in $PATH[2]. However, 'python' is used instead of 'python3' as the
scripts are compatible with both.
[1] https://linux.die.net/man/2/execve
[2] http://cgit.openembedded.org/openembedded-core/commit/?id=eef7883587acc933d6f34b559ec03ff84d18573b
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: David Owens <david.owens@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libglib2 is licensed under LGPL-2.1+ and not LGPL-2.0+ since release
2.53.3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the bump of libglib2 to 2.56.0, it fails to build on uClibc with:
gthreadedresolver.c: In function 'do_lookup_records':
gthreadedresolver.c:875:16: error: 'res' undeclared (first use in this function); did you mean '_res'?
res_nclose (&res);
^~~
_res
This commit adds an upstream patch that fixes this problem.
Fixes:
http://autobuild.buildroot.net/results/990e19e3500986263f99354215e33214a2e89116/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libglib2 recently changed to use the result of the autoconf macro to
decide how to use strerror_r() in g_strerror() instead of embedding the
same preprocessor condition as in glibc's strings.h (upstream commit
c8e268bb was first included in release 2.53.4).
Following this change, if ac_cv_func_strerror_r_char_p is incorrectly
set to "no", the error string is an uninitialized buffer which cannot be
encoded as UTF-8. The final result of this is that GLib functions that
are expected to fill in an error pointer on failure in fact leave this
pointing to NULL which is likely to cause a segfault in client
applications.
In fact the autoconf check compiles a test file but does not need to run
it, so the test is safe when cross-compiling and returns the correct
answer. So remove this cached value and let the configure script figure
it out for itself, fixing g_strerror() on glibc systems.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Patch 0002-disable-tests.patch modifies Makefile.am, so we have to
autoreconf. It hasn't been seen until now, but becomes very clear
since the bump of automake to 1.15.1, as we're seeing build failures
such as:
configure.ac:66: error: version mismatch. This is Automake 1.15.1,
configure.ac:66: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:66: comes from Automake 1.15. You should recreate
configure.ac:66: aclocal.m4 with aclocal and run automake again.
Fixes:
http://autobuild.buildroot.net/results/3402357d8e90f1866dfeaee7bb61119d80dc8bcb/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
By default, libglib enables some fairly aggressive warnings, treated
as errors. In particular, the -Wformat=2 warning triggers a warning
due to the return value of the ngettext() macro from uClibc libintl
stub not being understood as being potentially a format string.
So, before we enable the stub libintl in uClibc, we disable such
warnings. A bug will be reported to upstream uClibc to get the actual
bug fixed, but disabling compiler warnings treated as errors is anyway
a good thing in the context of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Patches were changed to git format, because libglib is a git project.
0003-gio-2.0.pc-include-libmount-in-Libs.private.patch was added to upstream
as of commit:
https://git.gnome.org/browse/glib/commit/?id=ecdd3c29fc4bd28f01fe53d0528bfee888c9c62c.
Signed-off-by: Adam Duskett <aduskett@codeblue.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check-package script when ran gives warnings on ordering issues
on all of these Config files. This patch cleans up all warnings
related to the ordering in the Config files for packages starting with
the letter l in the package directory.
The appropriate ordering is: type, default, depends on, select, help
See http://nightly.buildroot.org/#_config_files for more information.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We want to use SPDX identifier for license string as much as possible.
SPDX short identifier for LGPLv2/LGPLv2+ is LGPL-2.0/LGPL-2.0+.
This change is done using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/LGPLv2(\+)?/LGPL-2.0\1/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 4c7c010f9f.
The bump to libglib2 2.25.0 causes a large number of build failures due
to the redefinition of crc32() in both util-linux libblkid and
zlib.
Fixes:
http://autobuild.buildroot.net/results/ac65c9177dd63fc8d76dba3b9845f81b15faa716/
(and approximately 500 other similar build failures)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 71c5a81c96.
The bump to libglib2 2.25.0 causes a large number of build failures due
to the redefinition of crc32() in both util-linux libblkid and
zlib. This commit is related to the bump, so it needs to get reverted as
well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It now requires util-linux libmount so add the dependency/select.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Register package-specific target-finalize hooks with the
newly-introduced <PKG>_TARGET_FINALIZE_HOOKS.
This incidentally fixes luarocks, which was registering target-finalize
hooks even when it was not enabled.
To be noted, the skeleton package is not converted, because it is not
optional, we always have it; so its hooks would always be registered
anyway. Besides, the followup patches would render this conversion moot
anyway, since those hooks would be spread across the various skeleton
packages.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
