gobject-introspection: New package

From: Adam Duskett <[email protected]>

Some packages, like prelink-cross, will want to use libiberty but do not bundle their own instance (which is good!).

However, libiberty is made for being bundled in packages: all GNU packages that use libiberty (gcc, binutils, gdb et al...) all have their own bundled variant. This means that there is no official upstream for libiberty; the closest being as part of the combined binutils-gdb tree.

So we introduce a new host-only package, that installs just libiberty from a binutils released tarball.

Again, as libiberty is usually bundled in packages, it usually only install a static version. Furthermore, it does not obey to the usual

--enable-shared and --disable-static flags; it only ever builds a static version.

Furthermore, this library is not built with -fPIC, but some packages may pick it to build shared objects. This is the case for host-gdb, for example, which accidentally picks that library instead of its internal one.

So, rather than fix the various gdb versions and variants we can use, we ensure that the libiberty we install is usable in shared objects, and we ensure it is always built before host-gdb.

Signed-off-by Adam Duskett <[email protected]>

---
Changes v1 -> v11:
- Add this patch to the series

 DEVELOPERS                       |  1 +
 package/libiberty/libiberty.hash |  2 ++
 package/libiberty/libiberty.mk   | 27 +++++++++++++++++++++++++++
 3 files changed, 30 insertions(+)
 create mode 100644 package/libiberty/libiberty.hash
 create mode 100644 package/libiberty/libiberty.mk

DEVELOPERS +1 -0

index 906ccae006..f10711ee6a 100644
@@ -2426,6 +2426,7 @@ F:        package/keyutils/
 F:     package/libbsd/
 F:     package/libedit/
 F:     package/libgsm/
+F:     package/libiberty/
 F:     package/libinput/
 F:     package/libiscsi/
 F:     package/libpri/

package/libiberty/libiberty.hash new file +2 -0

new file mode 100644
index 0000000000..270f38dfa7
@@ -0,0 +1,2 @@
+# From ftp://gcc.gnu.org/pub/binutils/releases/sha512.sum
+sha512  d326408f12a03d9a61a9de56584c2af12f81c2e50d2d7e835d51565df8314df01575724afa1e43bd0db45cfc9916b41519b67dfce03232aa4978704492a6994a  binutils-2.32.tar.xz

package/libiberty/libiberty.mk new file +27 -1

new file mode 100644
index 0000000000..17976fdd4f
@@ -0,0 +1,27 @@
+################################################################################
+#
+# libiberty
+#
+################################################################################
+
+LIBIBERTY_VERSION = 2.32
+LIBIBERTY_SOURCE = binutils-$(LIBIBERTY_VERSION).tar.xz
+LIBIBERTY_SITE = $(BR2_GNU_MIRROR)/binutils
+LIBIBERTY_DL_SUBDIR = binutils
+LIBIBERTY_SUBDIR = libiberty
+
+# We explicitly disable multilib, as we do in binutils.
+# By default, libiberty installs nothing, so we must force it.
+HOST_LIBIBERTY_CONF_OPTS = \
+       --disable-multilib \
+       --enable-install-libiberty
+
+# Some packages (e.g. host-gdb) will pick this library and build shared
+# objects with it. But libiberty does not honour the --enable-shared and
+# --disable-static flags; it only ever builds a static library no matter
+# what. So we must force -fPIC in build flags.
+HOST_LIBIBERTY_CONF_ENV = \
+       CFLAGS="$(HOST_CFLAGS) -fPIC" \
+       LDFLAGS="$(HOST_LDFLAGS) -fPIC"
+
+$(eval $(host-autotools-package))
--

2.21.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

package/pkg-meson.mk define $(2)_CONFIGURE_CMDS · line 87

Quoted 1 line · On Mon, 21 Oct 2019 13:04:37 -0700 aduskett at gmail.com wrote:

package/pkg-meson.mk +1 -0

+	_PYTHON_SYSCONFIGDATA_NAME="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" \

Why do we need this conditional on BR2_PACKAGE_PYTHON3 ? package/pkg-python.mk is using PKG_PYTHON_SYSCONFIGDATA_NAME unconditionally, regardless of Python 2.x vs. Python 3.x. Could you explain this ?

Note that this patch was authored by me, Adam accidentally took over authorship
(which is why he said on IRC he needs to send a v15).

Quoted 9 lines · Thomas Petazzoni

package/pkg-meson.mk define $(2)_CONFIGURE_CMDS · line 87

Quoted 1 line · On Mon, 21 Oct 2019 13:04:37 -0700 aduskett at gmail.com wrote:

package/pkg-meson.mk +1 -0

+	_PYTHON_SYSCONFIGDATA_NAME="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" \

Why do we need this conditional on BR2_PACKAGE_PYTHON3 ? package/pkg-python.mk is using PKG_PYTHON_SYSCONFIGDATA_NAME unconditionally, regardless of Python 2.x vs. Python 3.x. Could you explain this ?

I can :-)

It's a mistake. I noticed that PKG_PYTHON_SYSCONFIGDATA_NAME was left empty for
python2, so I made sure it got the correct value (in Python2 there is only one _sysconfigdata). However, python2 doesn't have the _PYTHON_SYSCONFIGDATA_NAME variable so it's meaningless.

Should be tested if things work OK with python2 on target, but I expect they do.

Quoted 14 lines · Arnout Vandecappelle

Note that this patch was authored by me, Adam accidentally took over authorship
(which is why he said on IRC he needs to send a v15).

Quoted 9 lines · Thomas Petazzoni

Quoted 1 line · On Mon, 21 Oct 2019 13:04:37 -0700 aduskett at gmail.com wrote:

+ _PYTHON_SYSCONFIGDATA_NAME="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" \

Why do we need this conditional on BR2_PACKAGE_PYTHON3 ? package/pkg-python.mk is using PKG_PYTHON_SYSCONFIGDATA_NAME unconditionally, regardless of Python 2.x vs. Python 3.x. Could you explain this ?

Quoted 8 lines

I can :-)

It's a mistake. I noticed that PKG_PYTHON_SYSCONFIGDATA_NAME was left empty for
python2, so I made sure it got the correct value (in Python2 there is only one _sysconfigdata). However, python2 doesn't have the _PYTHON_SYSCONFIGDATA_NAME variable so it's meaningless.

Should be tested if things work OK with python2 on target, but I expect they do.

I hadn't read Adam's remark in the cover letter yet, about how this patch
breaks the build of libglib2.

I suspect that we shold not set _PYTHON_SYSCONFIGDATA_NAME if python3 is not
selected. Indeed, python3 *will* observe this environment variable, but if target python3 is not selected, it will be empty. meson will do checks for host-python, and setting that environment variable will break the check (which is BTW an example of the comment I made in the commit log of this patch: "Note that this approach will still break things when meson needs to build something for the host during a target build."). libglib2 indeed does use python3 during the build, so it asks meson to check for it, but since it doesn't try to build C modules for the host, it still works even with a wrong _sysconfigdata.

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

Regards,
Arnout

Quoted 14 lines · Arnout Vandecappelle

Note that this patch was authored by me, Adam accidentally took over authorship
(which is why he said on IRC he needs to send a v15).

Quoted 9 lines · Thomas Petazzoni

Quoted 1 line · On Mon, 21 Oct 2019 13:04:37 -0700 aduskett at gmail.com wrote:

+ _PYTHON_SYSCONFIGDATA_NAME="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" \

Why do we need this conditional on BR2_PACKAGE_PYTHON3 ? package/pkg-python.mk is using PKG_PYTHON_SYSCONFIGDATA_NAME unconditionally, regardless of Python 2.x vs. Python 3.x. Could you explain this ?

Quoted 8 lines

I can :-)

It's a mistake. I noticed that PKG_PYTHON_SYSCONFIGDATA_NAME was left empty for
python2, so I made sure it got the correct value (in Python2 there is only one _sysconfigdata). However, python2 doesn't have the _PYTHON_SYSCONFIGDATA_NAME variable so it's meaningless.

Should be tested if things work OK with python2 on target, but I expect they do.

I hadn't read Adam's remark in the cover letter yet, about how this patch
breaks the build of libglib2.

I suspect that we shold not set _PYTHON_SYSCONFIGDATA_NAME if python3 is not
selected. Indeed, python3 *will* observe this environment variable, but if target python3 is not selected, it will be empty. meson will do checks for host-python, and setting that environment variable will break the check (which is BTW an example of the comment I made in the commit log of this patch: "Note that this approach will still break things when meson needs to build something for the host during a target build."). libglib2 indeed does use python3 during the build, so it asks meson to check for it, but since it doesn't try to build C modules for the host, it still works even with a wrong _sysconfigdata.

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

Regards,
Arnout

Quoted 5 lines

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

$$(if $$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" Also does not work, because the target python3 may not yet be built.

Quoted 7 lines · On Wed, 23 Oct 2019 13:42:54 -0700 Adam Duskett <[email protected]> wrote:

Quoted 5 lines

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

$$(if $$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" Also does not work, because the target python3 may not yet be built.

But that is totally unrelated to the _sysconfigdata "fallback" that I was criticizing. The issue of "you're passing _PYTHON_SYSCONFIG_DATA_NAME regardless of whether Python was built before or not" was already present in your initial submission.

Quoted 10 lines · Thomas Petazzoni

Quoted 7 lines · On Wed, 23 Oct 2019 13:42:54 -0700 Adam Duskett <[email protected]> wrote:

Quoted 5 lines

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

$$(if $$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" Also does not work, because the target python3 may not yet be built.

Ugh indeed, another side effect of this environment being used for both "host"
python and "cross" python...

I'm starting to think this is not such a good solution after all...

Quoted 4 lines

But that is totally unrelated to the _sysconfigdata "fallback" that I was criticizing. The issue of "you're passing _PYTHON_SYSCONFIG_DATA_NAME regardless of whether Python was built before or not" was already present in your initial submission.

With "initial submission", do you mean *my* initial submission (i.e. this patch
4/5 from v14), or Adam's initial submission which patched meson itself and which was taken over from yocto? The latter did not actually change sysconfigdata at all; instead it patched meson to not make use of the pkg_config_libdir that comes out of sysconfigdata (which is I think the only thing from sysconfigdata that is actually used by meson).

I'll dive into the meson code again to see if I can find something better...

Quoted 25 lines · Arnout Vandecappelle

Quoted 10 lines · Thomas Petazzoni

Quoted 7 lines · On Wed, 23 Oct 2019 13:42:54 -0700 Adam Duskett <[email protected]> wrote:

Quoted 5 lines

Adam, could you test if this works better?

+ $$(if
$$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME)") \

$$(if $$(BR2_PACKAGE_PYTHON3),_PYTHON_SYSCONFIGDATA_NAME="$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" Also does not work, because the target python3 may not yet be built.

Ugh indeed, another side effect of this environment being used for both "host"
python and "cross" python...

I'm starting to think this is not such a good solution after all...

Quoted 4 lines

But that is totally unrelated to the _sysconfigdata "fallback" that I was criticizing. The issue of "you're passing _PYTHON_SYSCONFIG_DATA_NAME regardless of whether Python was built before or not" was already present in your initial submission.

Quoted 8 lines

With "initial submission", do you mean *my* initial submission (i.e. this patch
4/5 from v14), or Adam's initial submission which patched meson itself and which was taken over from yocto? The latter did not actually change sysconfigdata at all; instead it patched meson to not make use of the pkg_config_libdir that comes out of sysconfigdata (which is I think the only thing from sysconfigdata that is actually used by meson).

I'll dive into the meson code again to see if I can find something better...

OK, I *think* I've come up with an alternative (but I'm sure as hell not going
to implement it :-).

Essentially, it's the same issue as for pkg-config: we should distinguish
between the host version and the cross version (i.e. executable that can run on the host but that returns results for the target). Meson is very explicit about such a distinction, so anything pertaining to cross-compilation should be passed through cross-compilation.conf instead of in the environment.

As far as I can see in the source code, we can in fact set a
"cross-compilation" python in the [binaries] section. So, we could create a python wrapper that sets those environment variables, and point to that python wrapper in the cross-compilation.conf.

And of course, we can use the same approach in pkg-python.mk: set
$(2)_PYTHON_INTERPRETER to the python wrapper instead of $(HOST_DIR)/bin/python.

Regards,
Arnout

From: Adam Duskett <[email protected]>

meson has support for Python dependencies, to e.g. build Python modules. It parses Python's sysconfig module to find the appropriate configuration variables. However, the sysconfig module is the one for the host, _not_ for the target. Therefore, wrong values may be set. Many of them get overridden anyway by the cross-compilation.conf. One particular one that is problematic is that it uses the python-XXX.pc pkg-config file for the host instead of the target, because it explicitly sets the PKG_CONFIG_LIBDIR found in sysconfig.

Use the same trick as for python package: pass PYTHONPATH, PYTHONNOUSERSITE and _PYTHON_SYSCONFIGDATA_NAME in the environment to point to staging instead of host. This ensures the sysconfig from the target is used instead of the one from the host.

An alternative would be to patch meson to not use the PKG_CONFIG_LIBDIR from sysconfig. However, it is likely that other problems will pop up at some point because of using the wrong sysconfig.

Note that this approach will still break things when meson needs to build something for the host during a target build.

Signed-off-by Adam Duskett <[email protected]>

---
Changes v1 -> v14:
- Add this patch to the series.

  package/pkg-meson.mk | 3 +++
  1 file changed, 3 insertions(+)

package/pkg-meson.mk +3 -0

index 184a22a44a..b6360fb738 100644
@@ -84,6 +84,9 @@ define $(2)_CONFIGURE_CMDS
  	    ) \
  	    package/meson/cross-compilation.conf.in \
  	    > $$($$(PKG)_SRCDIR)/build/cross-compilation.conf
+	_PYTHON_SYSCONFIGDATA_NAME="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PKG_PYTHON_SYSCONFIGDATA_NAME),_sysconfigdata)" \
+	PYTHONPATH="$$(if $$(BR2_PACKAGE_PYTHON3),$$(PYTHON3_PATH),$$(PYTHON_PATH))" \
+	PYTHONNOUSERSITE=1 \
  	PATH=$$(BR_PATH) $$($$(PKG)_CONF_ENV) $$(MESON) \
  		--prefix=/usr \
  		--libdir=lib \

There are seven total patches and four different wrapper files needed to successfully cross-compile and run this package, many of them are from open-embedded, but two of them are of my own doing.

1) Revert a previous, incomplete attempt at adding cross-compiling support.

2) Add support for cross compiling with meson.

3) Disable tests when cross-compiling.

4) Add support for the various wrappers. (See patch for details.)

5) Add an option to use a binary wrapper; this patch will force giscanner to use a wrapper executable to run binaries it's producing, instead of attempting to run them from the host.

6) Add an option to use an LDD wrapper, again, useful for cross-compiled environments.

7) Add a --lib-dirs-envar option to pass to giscanner. (See patch for details.)

8) Add rpath-links to ccompiler: when passing the PACKAGE_GIR_EXTRA_LIBS_PATH to the ccompiler.py script, ccompiler.py needs to add -Wl,-rpath-link to the environment for the package to correctly link against the passed on paths.

9) Ignore error return codes from ldd-wrapper because prelink-rtld returns 127 when it can't find a library, which will break subprocess.check_output().

package/gobject-introspection/0007-Add-rpath-links-to-ccompiler.patch new file +14 -0

+---
+ giscanner/ccompiler.py | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/giscanner/ccompiler.py b/giscanner/ccompiler.py
+index a8bd5b1..51bb9bc 100644
+--- a/giscanner/ccompiler.py
++++ b/giscanner/ccompiler.py
+@@ -229,6 +229,8 @@ class CCompiler(object):
+ 
+         for envvar in runtime_path_envvar:
+             if envvar in os.environ:
++                for envvar_path in os.environ[envvar].split(':'):
++                    args.append("-Wl,-rpath-link," + envvar_path)

+GOBJECT_INTROSPECTION_LICENSE_FILES = COPYING.LGPL COPYING.GPL

package/gobject-introspection/gobject-introspection.mk new file +20 -0

+HOST_GOBJECT_INTROSPECTION_DEPENDENCIES = \
+	host-bison \
+	host-flex \
+	host-libglib2 \
+	host-python3
+
+# g-ir-scanner will default to /usr/bin/ld for linking if this is not set.
+GOBJECT_INTROSPECTION_NINJA_ENV += \
+	CC="$(TARGET_CC)"
+
+# Use the host gi-scanner to prevent the scanner from generating incorrect
+# elf classes.
+GOBJECT_INTROSPECTION_CONF_OPTS = \
+	-Denable-host-gi=true \
+	-Denable-gi-cross-wrapper="$(STAGING_DIR)/usr/bin/g-ir-scanner-qemuwrapper" \
+	-Denable-gi-ldd-wrapper="$(STAGING_DIR)/usr/bin/g-ir-scanner-lddwrapper" \
+	-Denable-introspection-data=true
+
+ifeq ($(BR2_PACKAGE_CAIRO),y)
+GOBJECT_INTROSPECTION_DEPENDENCIES += cairo

package/gobject-introspection/gobject-introspection.mk new file +13 -0

+# Make sure g-ir-tool-template uses the host python.
+define GOBJECT_INTROSPECTION_FIX_TOOLTEMPLATE_PYTHON_PATH
+	$(SED) '1s%#!.*%#!$(HOST_DIR)/bin/python%' $(@D)/tools/g-ir-tool-template.in
+endef
+GOBJECT_INTROSPECTION_PRE_CONFIGURE_HOOKS += GOBJECT_INTROSPECTION_FIX_TOOLTEMPLATE_PYTHON_PATH
+HOST_GOBJECT_INTROSPECTION_PRE_CONFIGURE_HOOKS += GOBJECT_INTROSPECTION_FIX_TOOLTEMPLATE_PYTHON_PATH
+
+# These wrappers allow gobject-introspection to build the internal introspection
+# libraries during the build process.
+define GOBJECT_INTROSPECTION_INSTALL_PRE_WRAPPERS
+	$(INSTALL) -D -m 755 $(GOBJECT_INTROSPECTION_PKGDIR)/g-ir-scanner-lddwrapper.in \
+		$(STAGING_DIR)/usr/bin/g-ir-scanner-lddwrapper
+	$(INSTALL) -D -m 755 $(GOBJECT_INTROSPECTION_PKGDIR)/g-ir-scanner-qemuwrapper.in \

package/gobject-introspection/gobject-introspection.mk new file +5 -0

+endef
+GOBJECT_INTROSPECTION_TARGET_FINALIZE_HOOKS += GOBJECT_INTROSPECTION_REMOVE_DEVELOPMENT_FILES
+
+$(eval $(meson-package))
+$(eval $(host-meson-package))

From: Adam Duskett <[email protected]>

Included in version 14 of the gobject-introspection patch series. The patch series is almost identical with V13 except for one significant change:

With permission from Arnout I have included the patch:
package/pkg-meson.mk: set Python sysconfigdata However; the patch has one big flaw I would like to discuss:

The patch breaks libglib2 if a target-python is not selected or is not yet
built and installed before building target libglib2. Indeed, it would be
because we would pass _PYTHON_SYSCONFIGDATA_NAME="" as an environment
variable, which leads to the following error during libglib2-configure:
meson.build:1978:0: ERROR: <ExternalProgram 'python3' -> ['output/host/bin/python3']> is not a valid python or it is missing setuptools

However, I do believe the patch is a better direction to go than the previous
patch: package/meson: prevent python include path manipulation for two significant reasons:

1) Meson does not have to be patched.
2) It fixes the suffix of built python applications that use meson (such as newer versions of python-gobject.) With the old patch, the suffix of the python libraries is -x86-64 even though the binaries themselves would be the target architecture, which causes import errors on the target. With this patch, the suffix is correct.

I propose keeping the patch but modifying it to work correctly if the target-python isn't selected or isn't yet built. I need help however with this as I am not great with makefile syntax this complex.

Thanks!

Adam

Adam Duskett (5):
package/libiberty: new package
package/prelink-cross: new package
package/gdb: depend on libiberty
package/pkg-meson.mk: set Python sysconfigdata
package/gobject-introspection: new package

  DEVELOPERS                                    |   3 +
  package/Config.in                             |   1 +
  package/gdb/gdb.mk                            |   4 +-
  ...lete-upstream-attempt-at-cross-compi.patch |  33 ++++
  ...d-cross-compilation-support-to-meson.patch | 163 ++++++++++++++++++
  ...d-disable-tests-when-cross-compiling.patch |  27 +++
  ...canner-add-use-binary-wrapper-option.patch |  52 ++++++
  ...scanner-add-a-use-ldd-wrapper-option.patch |  48 ++++++
  ...scanner-add-a-lib-dirs-envvar-option.patch |  73 ++++++++
  .../0007-Add-rpath-links-to-ccompiler.patch   |  29 ++++
  ...-error-return-codes-from-ldd-wrapper.patch |  28 +++
  package/gobject-introspection/Config.in       |  26 +++
  .../gobject-introspection/g-ir-compiler.in    |   2 +
  .../g-ir-scanner-lddwrapper.in                |   2 +
  .../g-ir-scanner-qemuwrapper.in               |  17 ++
  package/gobject-introspection/g-ir-scanner.in |   7 +
  .../gobject-introspection.hash                |   4 +
  .../gobject-introspection.mk                  | 103 +++++++++++
  package/libiberty/libiberty.hash              |   2 +
  package/libiberty/libiberty.mk                |  27 +++
  package/pkg-meson.mk                          |   3 +
  package/prelink-cross/prelink-cross.hash      |   3 +
  package/prelink-cross/prelink-cross.mk        |  16 ++
  23 files changed, 672 insertions(+), 1 deletion(-)

create mode 100644 package/gobject-introspection/0001-Revert-an-incomplete-upstream-attempt-at-cross-compi.patch create mode 100644 package/gobject-introspection/0002-add-cross-compilation-support-to-meson.patch create mode 100644 package/gobject-introspection/0003-meson.build-disable-tests-when-cross-compiling.patch create mode 100644 package/gobject-introspection/0004-giscanner-add-use-binary-wrapper-option.patch create mode 100644 package/gobject-introspection/0005-giscanner-add-a-use-ldd-wrapper-option.patch create mode 100644 package/gobject-introspection/0006-giscanner-add-a-lib-dirs-envvar-option.patch create mode 100644 package/gobject-introspection/0007-Add-rpath-links-to-ccompiler.patch create mode 100644 package/gobject-introspection/0008-ignore-error-return-codes-from-ldd-wrapper.patch create mode 100644 package/gobject-introspection/Config.in
create mode 100644 package/gobject-introspection/g-ir-compiler.in
create mode 100644 package/gobject-introspection/g-ir-scanner-lddwrapper.in
create mode 100644 package/gobject-introspection/g-ir-scanner-qemuwrapper.in
create mode 100644 package/gobject-introspection/g-ir-scanner.in
create mode 100644 package/gobject-introspection/gobject-introspection.hash
create mode 100644 package/gobject-introspection/gobject-introspection.mk
create mode 100644 package/libiberty/libiberty.hash
create mode 100644 package/libiberty/libiberty.mk
create mode 100644 package/prelink-cross/prelink-cross.hash
create mode 100644 package/prelink-cross/prelink-cross.mk