Reproducible builds

The use __DATE__ and __TIME__ are one of most common sources of non-reproducible binaries. In order to fix that, gcc begin to support SOURCE_DATE_EPOCH variable. This patch take advantage of toolchain-wrapper to provide support of SOURCE_DATE_EPOCH to older gcc versions.

Function get_source_date_epoch() come directly from gcc git.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

The use __DATE__ and __TIME__ are one of most common sources of

non-reproducible binaries. In order to fix that, gcc begin to support SOURCE_DATE_EPOCH variable. This patch take advantage of toolchain-wrapper to provide support of SOURCE_DATE_EPOCH to older gcc versions.

Function get_source_date_epoch() come directly from gcc git.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v3:
- Handle $SOURCE_DATE_EPOCH at runtime (Thomas)
v2:
- Overload __TIME__ and __DATE__ instead of patching gcc (Thomas)

 toolchain/toolchain-wrapper.c | 74 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 73 insertions(+), 1 deletion(-)

toolchain/toolchain-wrapper.c +1 -0

index d59629b..6150574 100644
@@ -22,12 +22,17 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <errno.h>
+#include <time.h>

toolchain/toolchain-wrapper.c +4 -1

 /**
  * GCC errors out with certain combinations of arguments (examples are

@@ -39,8 +44,11 @@ static char sysroot[PATH_MAX];
  * 	-mfloat-abi=
  * 	-march=
  * 	-mcpu=
+ * 	-D__TIME__=
+ * 	-D__DATE__=
+ * 	-Wno-builtin-macro-redefined
  */
-#define EXCLUSIVE_ARGS	3
+#define EXCLUSIVE_ARGS	6
 
 static char *predef_args[] = {
 #ifdef BR_CCACHE

toolchain/toolchain-wrapper.c +11 -0

+	if ((errno == ERANGE && (epoch == LLONG_MAX || epoch == LLONG_MIN))
+			|| (errno != 0 && epoch == 0)) {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"strtoll: %s\n", strerror(errno));
+		exit(2);
+	}
+	if (endptr == source_date_epoch) {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"no digits were found: %s\n", endptr);
+		exit(2);
+	}

toolchain/toolchain-wrapper.c static void check_unsafe_path(const char *arg, · line 165

Quoted 11 lines

toolchain/toolchain-wrapper.c +11 -0

+{
+	char *source_date_epoch;
+	long long epoch;
+	char *endptr;
+
+	source_date_epoch = getenv("SOURCE_DATE_EPOCH");
+	if (!source_date_epoch)
+		return (time_t) -1;
+
+	errno = 0;
+	epoch = strtoll (source_date_epoch, &endptr, 10);

NIT: No space between strtoll and '('.

Quoted 15 lines

toolchain/toolchain-wrapper.c +15 -0

+	if ((errno == ERANGE && (epoch == LLONG_MAX || epoch == LLONG_MIN))
+			|| (errno != 0 && epoch == 0)) {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"strtoll: %s\n", strerror(errno));
+		exit(2);
+	}
+	if (endptr == source_date_epoch) {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"no digits were found: %s\n", endptr);
+		exit(2);
+	}
+	if (*endptr != '\0') {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"trailing garbage: %s\n", endptr);
+		exit(2);

toolchain/toolchain-wrapper.c static void check_unsafe_path(const char *arg, · line 186

Quoted 6 lines

toolchain/toolchain-wrapper.c +6 -0

+	}
+	if (epoch < 0) {
+		fprintf(stderr, "environment variable $SOURCE_DATE_EPOCH: "
+				"value must be nonnegative: %lld \n", epoch);
+		exit(2);
+	}

I'm not sure this detailed error handling is really needed, but OK.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

Quoted 1 line

I'm not sure this detailed error handling is really needed, but OK.

In fact I copy-paste get_source_date_epoch() from gcc git. So toolchain wrapper will produce exactly same error messages than upstream gcc (and it include same coding style error :-) ).

Quoted 1 line

I'm not sure this detailed error handling is really needed, but OK.

In fact I copy-paste get_source_date_epoch() from gcc git. So toolchain wrapper will produce exactly same error messages than upstream gcc (and it include same coding style error :-) ).

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,
On Wed, 08 Feb 2017 11:07:07 +0100, J?r?me Pouiller wrote:

Quoted 5 lines

Quoted 1 line

I'm not sure this detailed error handling is really needed, but OK.

In fact I copy-paste get_source_date_epoch() from gcc git. So toolchain wrapper will produce exactly same error messages than upstream gcc (and it include same coding style error :-) ).

So now our toolchain-wrapper is under GPLv3 :-/

Quoted 3 lines · Thomas Petazzoni

Quoted 1 line · J?r?me Pouiller

Quoted 1 line

I'm not sure this detailed error handling is really needed, but

Quoted 2 lines

Quoted 2 lines

In fact I copy-paste get_source_date_epoch() from gcc git. So

Quoted 4 lines

Quoted 2 lines

wrapper will produce exactly same error messages than upstream gcc (and it include same coding style error :-) ).

So now our toolchain-wrapper is under GPLv3 :-/

Yes, if the function is considered large and and original enough to be considered copyrightable - Afterall it is just a getenv + strtoll and

bit of error checking.

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

Yes, if the function is considered large and and original enough to be considered copyrightable - Afterall it is just a getenv + strtoll and a bit of error checking.

I am not a lawyer, but my code is clearly a "derivative work" of get_source_date_epoch() from gcc.

What do you prefer?

1. Revert and rewrite function: it is not a big amount of work.

2. Postpone problem: Buildroot also contains patches under GPLv3 and anyway, users will use a GPLv3 compiler.

Quoted 2 lines

2. Postpone problem: Buildroot also contains patches under GPLv3 and anyway, users will use a GPLv3 compiler.

I think that is the most sensible thing to do. What do others say?

`date' is widely used by packages to include build information in their binaries. Unfortunately, this is incompatible with BR2_REPRODUCIBLE.

Instead of having to identify all `date' invocations in the different packages, this commit adds a small tool that allows to always return the same date.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

`date' is widely used by packages to include build information in their binaries. Unfortunately, this is incompatible with BR2_REPRODUCIBLE.

Instead of having to identify all `date' invocations in the different packages, this commit adds a small tool that allows to always return the same date.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v3:
- Do not force $PATH. Find true `date' binary instead (Thomas)
- Add explanations (Thomas)
- Fix options detection (Arnout)
- Rename INHIBIT in FORCE_EPOCH (Thomas)
- Break after FORCE_EPOCH=0 (Arnout)
- Add support for '--reference'
- Add full copyright blurb (Arnout)

Quoted 3 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

`date' is widely used by packages to include build information in

Quoted 1 line

binaries. Unfortunately, this is incompatible with

Quoted 2 lines

Instead of having to identify all `date' invocations in the

Quoted 1 line

packages, this commit adds a small tool that allows to always

Quoted 1 line

the same date.

Would using something like libfaketime not be a more generic solution?

https://github.com/wolfcw/libfaketime

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

`date' is widely used by packages to include build information in their binaries. Unfortunately, this is incompatible with BR2_REPRODUCIBLE.

Instead of having to identify all `date' invocations in the different packages, this commit adds a small tool that allows to always return the same date.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v3:
- Do not force $PATH. Find true `date' binary instead (Thomas)
- Add explanations (Thomas)
- Fix options detection (Arnout)
- Rename INHIBIT in FORCE_EPOCH (Thomas)
- Break after FORCE_EPOCH=0 (Arnout)
- Add support for '--reference'
- Add full copyright blurb (Arnout)

 package/fakedate/fakedate    | 59 ++++++++++++++++++++++++++++++++++++++++++++
 package/fakedate/fakedate.mk | 15 +++++++++++
 2 files changed, 74 insertions(+)
 create mode 100755 package/fakedate/fakedate
 create mode 100644 package/fakedate/fakedate.mk

package/fakedate/fakedate new file +44 -0

new file mode 100755
index 0000000..074c517
@@ -0,0 +1,59 @@
+#!/bin/sh
+# vim: set sw=4 expandtab:
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+#
+# Copyright (C) 2016 J?r?me Pouiller <[email protected]>
+#
+LOG=/dev/null
+
+# Sanity check
+if ! readlink -f "$0" | grep -q fakedate; then
+    echo "fakedate: Please name this script \`fakedate'"
+    exit 1
+fi
+
+DATE_BIN=false
+# Do not call `date'd directly since it will produce an infinite recursion.
+# Instead, find path of true `date' binary.
+for P in `echo $PATH | tr ':' ' '`; do
+    if [ -x "$P/date" ]; then
+        if readlink -f "$P/date" | grep -qv fakedate; then
+            DATE_BIN="$P/date"
+            break;
+        fi
+    fi
+done
+
+if [ -n "$SOURCE_DATE_EPOCH" ]; then
+    FORCE_EPOCH=1
+    for i in "$@"; do
+        # Use of --date, --file and --reference (and their short option counter
+        # parts) is incompatible with SOURCE_DATE_EPOCH.

Usually, Buildroot does never initialize variables with empty content. DEPENDENCIES_HOST_PREREQ was an unjustified exception.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Enable fakedate for whole build process.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v3:
- Build host-fakedate before toolchain (Thomas)

 Makefile | 1 +
 1 file changed, 1 insertion(+)

Makefile +1 -1

index b80b9e1..ad7fde5 100644
@@ -254,6 +254,7 @@ export LC_ALL = C
 export GZIP = -n
 BR2_VERSION_GIT_EPOCH = $(shell GIT_DIR=$(TOPDIR)/.git $(GIT) log -1 --format=%at)
 export SOURCE_DATE_EPOCH = $(if $(wildcard $(TOPDIR)/.git),$(BR2_VERSION_GIT_EPOCH),$(BR2_VERSION_EPOCH))
+DEPENDENCIES_HOST_PREREQ += host-fakedate
 endif
 
 # To put more focus on warnings, be less verbose as default
--

1.9.1

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"J?r?me" == J?r?me Pouiller <[email protected]> writes:

Enable fakedate for whole build process.
This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v3:
- Build host-fakedate before toolchain (Thomas)

By default, compile_dir() rely on modification time to know if a python file have to be built again. However in some circumstances (when doing reproducible builds), modification times are not reliable. Thus, this patch add a way to force rebuild of all python sources.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v5:
- Improve commit log
v3:
- new patch

 support/scripts/pycompile.py | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

support/scripts/pycompile.py +10 -2

index fde711a..5598f8a 100644
@@ -10,6 +10,7 @@ from __future__ import print_function
 import sys
 import py_compile
 import compileall
+import argparse
 
 class ReportProblem:
     def __nonzero__(self):

@@ -21,4 +22,12 @@ class ReportProblem:
 
 report_problem = ReportProblem()
 
-compileall.compile_dir(sys.argv[1], quiet=report_problem)
+parser = argparse.ArgumentParser(description='Compile Python source files in a directory tree.')
+parser.add_argument("target", metavar='DIRECTORY',
+        help='Directory to scan')
+parser.add_argument("--force", action='store_true',
+        help="Force compilation even if alread compiled")
+
+args = parser.parse_args()
+
+compileall.compile_dir(args.target, force=args.force, quiet=report_problem)
--

1.9.1

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

By default, compile_dir() rely on modification time to know if a python file have to be built again. However in some circumstances (when doing reproducible builds), modification times are not reliable. Thus, this patch add a way to force rebuild of all python sources.

Signed-off-by J?r?me Pouiller <[email protected]>

---

.pyc files contain modification time of .py source. In order to make build reproducible, we fix modification time of all .py before compiling .pyc files.

In add, since pycompile rely on modification times to know if a file need to be recompiled, it is safer to force recompilation of all source files.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v5:
- Typo in commit log
- Explain why we pass --force to pycompile
- Fix indent
v3:
- Force compilation instead of removing .pyc

 package/python/python.mk | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

package/python/python.mk +9 -2

index cfd5a0a..cbe7c19 100644
@@ -233,10 +233,18 @@ PYTHON_PATH = $(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)/sysconfigdata/
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))
 
+ifeq ($(BR2_REPRODUCIBLE),y)
+define PYTHON_FIX_TIME
+       find $(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR) -name '*.py' -print0 | \
+               xargs -0 --no-run-if-empty touch -d @$(SOURCE_DATE_EPOCH)
+endef
+PYTHON_TARGET_FINALIZE_HOOKS += PYTHON_FIX_TIME
+endif
+
 define PYTHON_CREATE_PYC_FILES
        PYTHONPATH="$(PYTHON_PATH)" \
        $(HOST_DIR)/usr/bin/python$(PYTHON_VERSION_MAJOR) \
-               support/scripts/pycompile.py \
+               support/scripts/pycompile.py $(if $(BR2_REPRODUCIBLE),--force) \
                $(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)
 endef
 
--

1.9.1

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

.pyc files contain modification time of .py source. In order to make build reproducible, we fix modification time of all .py before compiling .pyc files.

In add, since pycompile rely on modification times to know if a file need to be recompiled, it is safer to force recompilation of all source files.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

.pyc files contain modification time of .py source. In order to make build reproducible, we fix modification time of all .py before compiling .pyc files.

In add, since pycompile rely on modification times to know if a file need to be recompiled, it is safer to force recompilation of all source files.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Notes:
v5:
- Typo in commit log
- Explain why we pass --force to pycompile
v3:
- Force compilation instead of removing .pyc

 package/python3/python3.mk | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

package/python3/python3.mk +9 -2

index 8bfae79..1817b22 100644
@@ -227,10 +227,18 @@ PYTHON3_PATH = $(TARGET_DIR)/usr/lib/python$(PYTHON3_VERSION_MAJOR)/sysconfigdat
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))
 
+ifeq ($(BR2_REPRODUCIBLE),y)
+define PYTHON3_FIX_TIME
+       find $(TARGET_DIR)/usr/lib/python$(PYTHON3_VERSION_MAJOR) -name '*.py' -print0 | \
+               xargs -0 --no-run-if-empty touch -d @$(SOURCE_DATE_EPOCH)
+endef
+PYTHON3_TARGET_FINALIZE_HOOKS += PYTHON3_FIX_TIME
+endif
+
 define PYTHON3_CREATE_PYC_FILES
        PYTHONPATH="$(PYTHON3_PATH)" \
        $(HOST_DIR)/usr/bin/python$(PYTHON3_VERSION_MAJOR) \
-               support/scripts/pycompile.py \
+               support/scripts/pycompile.py $(if $(BR2_REPRODUCIBLE),--force) \
                $(TARGET_DIR)/usr/lib/python$(PYTHON3_VERSION_MAJOR)
 endef
 
--

1.9.1

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

.pyc files contain modification time of .py source. In order to make build reproducible, we fix modification time of all .py before compiling .pyc files.

In add, since pycompile rely on modification times to know if a file need to be recompiled, it is safer to force recompilation of all source files.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

---

Some package includes some information from build environment in their results. This practice is incompatible with reproducible builds.

This patch scans final target to research most common patterns.

Since we only search fixed strings (grep is called with -F), this search is fast (on my station, 60ms for a target of 40MB).

Note, it could be a good idea to also match current user name. However, build path often contains username and, until now, we do not try to avoid build path in result.

Signed-off-by J?r?me Pouiller <[email protected]>

---
 Makefile | 5 +++++
 1 file changed, 5 insertions(+)

Makefile +5 -1

index ad7fde5..5b504c1 100644
@@ -708,6 +708,11 @@ endif
                $(call MESSAGE,"Executing post-build script $(s)"); \
                $(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
 
+ifeq ($(BR2_REPRODUCIBLE),y)
+       grep -raoF -e "`uname -r`" -e "`uname -v`" -e "`uname -n`" $(TARGET_DIR) | \
+               sed 's/\(.*\):\(.*\)/Warning: \1 may contain unreproducible information: \2/' | uniq
+endif
+
 target-post-image: $(TARGETS_ROOTFS) target-finalize
        @$(foreach s, $(call qstrip,$(BR2_ROOTFS_POST_IMAGE_SCRIPT)), \
                $(call MESSAGE,"Executing post-image script $(s)"); \
--

1.9.1

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

Some package includes some information from build environment in their results. This practice is incompatible with reproducible builds.

This patch scans final target to research most common patterns.

Since we only search fixed strings (grep is called with -F), this search is fast (on my station, 60ms for a target of 40MB).

Note, it could be a good idea to also match current user name. However, build path often contains username and, until now, we do not try to avoid build path in result.

Signed-off-by J?r?me Pouiller <[email protected]>

Quoted 8 lines

Some package includes some information from build environment in their results. This practice is incompatible with reproducible builds.

This patch scans final target to research most common patterns.

Since we only search fixed strings (grep is called with -F), this search is fast (on my station, 60ms for a target of 40MB).

Quoted 5 lines

Note, it could be a good idea to also match current user name. However, build path often contains username and, until now, we do not try to avoid build path in result.

Signed-off-by J?r?me Pouiller <[email protected]>

I am not entirely convinced it makes sense to grep more or less randomly in all files specifically for those strings.

Or perhaps, we should have a separate shell scripts that checks for several classes of obviously non-reproducible behaviors?

Thomas, J?r?me, All,

On 2017-04-01 16:50 +0200, Thomas Petazzoni spake thusly:

Quoted 13 lines · J?r?me Pouiller

Quoted 12 lines

Some package includes some information from build environment in their results. This practice is incompatible with reproducible builds.

This patch scans final target to research most common patterns.

Since we only search fixed strings (grep is called with -F), this search is fast (on my station, 60ms for a target of 40MB).

Note, it could be a good idea to also match current user name. However, build path often contains username and, until now, we do not try to avoid build path in result.

Quoted 4 lines

Quoted 1 line

Signed-off-by J?r?me Pouiller <[email protected]>

I am not entirely convinced it makes sense to grep more or less randomly in all files specifically for those strings.

Indeed. My hostnames usually cary some computer-related keywords, which can very well occur in binary files (e.g. 'segfault').

Quoted 3 lines

Or perhaps, we should have a separate shell scripts that checks for several classes of obviously non-reproducible behaviors?

Indeed, but such a script can only be a helper that a user would voluntarily run on their own.

We can't have such a script automatically run, because those strings can be too common.

.pyc files include path to source .py file. This patch changes the way `pycompile.py' is launched in order to only keep the part relative to $TARGET_DIR.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---

Notes:
v3:
- Typo in commit log (Arnout)

 package/python/python.mk | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

package/python/python.mk +4 -4

index cbe7c19..18ab14c 100644
@@ -243,9 +243,10 @@ endif
 
 define PYTHON_CREATE_PYC_FILES
        PYTHONPATH="$(PYTHON_PATH)" \
-       $(HOST_DIR)/usr/bin/python$(PYTHON_VERSION_MAJOR) \
-               support/scripts/pycompile.py $(if $(BR2_REPRODUCIBLE),--force) \
-               $(TARGET_DIR)/usr/lib/python$(PYTHON_VERSION_MAJOR)
+       cd $(TARGET_DIR) && $(HOST_DIR)/usr/bin/python$(PYTHON_VERSION_MAJOR) \
+               $(TOPDIR)/support/scripts/pycompile.py \
+               $(if $(BR2_REPRODUCIBLE),--force) \
+               usr/lib/python$(PYTHON_VERSION_MAJOR)
 endef
 
 ifeq ($(BR2_PACKAGE_PYTHON_PYC_ONLY)$(BR2_PACKAGE_PYTHON_PY_PYC),y)
--

1.9.1

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

.pyc files include path to source .py file. This patch changes the way `pycompile.py' is launched in order to only keep the part relative to $TARGET_DIR.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---

.pyc files include path to source .py file. This patch changes the way `pycompile.py' is launched in order to only keep the part relative to $TARGET_DIR.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---

Notes:
v3:
- Typo in commit log (Arnout)

 package/python3/python3.mk | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

package/python3/python3.mk +4 -4

index 1817b22..2562be7 100644
@@ -237,9 +237,10 @@ endif
 
 define PYTHON3_CREATE_PYC_FILES
        PYTHONPATH="$(PYTHON3_PATH)" \
-       $(HOST_DIR)/usr/bin/python$(PYTHON3_VERSION_MAJOR) \
-               support/scripts/pycompile.py $(if $(BR2_REPRODUCIBLE),--force) \
-               $(TARGET_DIR)/usr/lib/python$(PYTHON3_VERSION_MAJOR)
+       cd $(TARGET_DIR) && $(HOST_DIR)/usr/bin/python$(PYTHON3_VERSION_MAJOR) \
+               $(TOPDIR)/support/scripts/pycompile.py \
+               $(if $(BR2_REPRODUCIBLE),--force) \
+               usr/lib/python$(PYTHON3_VERSION_MAJOR)
 endef
 
 ifeq ($(BR2_PACKAGE_PYTHON3_PYC_ONLY)$(BR2_PACKAGE_PYTHON3_PY_PYC),y)
--

1.9.1

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

.pyc files include path to source .py file. This patch changes the way `pycompile.py' is launched in order to only keep the part relative to $TARGET_DIR.

This work was sponsored by `BA Robotic Systems'.

Signed-off-by J?r?me Pouiller <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

---

libtool include support for cross-compilation since v1.5. In order to enable it,

we have to pass --with-sysroot' to configure' script. With this option,

autoconf fill $lt_sysroot' and libtool will search libraries in $lt_sysroot'

subtree.

Note Yocto force `$lt_sysroot' even if --with-sysroot is not provided:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/pkg-autotools.mk | 1 +
 1 file changed, 1 insertion(+)

package/pkg-autotools.mk +1 -0

index f7b8488..bb20eec 100644
@@ -192,6 +192,7 @@ define $(2)_CONFIGURE_CMDS
 		--sysconfdir=/etc \
 		--localstatedir=/var \
 		--program-prefix="" \
+		--with-sysroot \
 		--disable-gtk-doc \
 		--disable-gtk-doc-html \
 		--disable-doc \

libtool include support for cross-compilation since v1.5.

Hello,

Quoted 1 line · J?r?me Pouiller

libtool include support for cross-compilation since v1.5.

Are you sure this is true?

In the release notes of libtool v2.4
(https://savannah.gnu.org/forum/forum.php?forum_id=6525), I see:

"""

New in 2.4 2010-09-22:

New features:

- Sysroot support. This allows you to build cross-compiled packages with the same prefix that will be used on the destination machine, and still find dependent libraries under the compiler's "sysroot". Without sysroot support, paths internal to the build system may leak into the product of the build.

Sysroot support is disabled unless the --with-sysroot configure option is passed to configure, because .la files generated with sysroot support will not be usable in general with older Libtools.

"""

So are you sure that this feature didn't appear in libtool 2.4 ?

Quoted 1 line

So are you sure that this feature didn't appear in libtool 2.4 ?

Yeah, looks like it. E.g. speex has libtool 1.5, and it doesn't have any
sysroot support (not in configure, not in ltmain.sh).

Obviously, *this* patch is not affected by it - it certainly doesn't hurt to
pass the --with-sysroot configure option. It's only patches 12+13 that we wouldn't be able to remove.

However, considering:

- most packages install things in /usr/lib, which is already searched by default;

- most packages use libtool 2.4 or later,

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

Hello,

Quoted 13 lines · Arnout Vandecappelle

Quoted 1 line

So are you sure that this feature didn't appear in libtool 2.4 ?

Yeah, looks like it. E.g. speex has libtool 1.5, and it doesn't have any
sysroot support (not in configure, not in ltmain.sh).

Obviously, *this* patch is not affected by it - it certainly doesn't hurt to
pass the --with-sysroot configure option. It's only patches 12+13 that we wouldn't be able to remove.

However, considering:

- most packages install things in /usr/lib, which is already searched by default;

Quoted 4 lines

- most packages use libtool 2.4 or later,

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

Since I would prefer to avoid autoreconfiguring many packages, it would be useful to know how many packages are still using libtool versions earlier than 2.4.

Hello,

Quoted 14 lines · Arnout Vandecappelle

Quoted 1 line

So are you sure that this feature didn't appear in libtool 2.4 ?

Yeah, looks like it. E.g. speex has libtool 1.5, and it doesn't have any
sysroot support (not in configure, not in ltmain.sh).

Obviously, *this* patch is not affected by it - it certainly doesn't hurt to pass the --with-sysroot configure option. It's only patches 12+13 that we wouldn't be able to remove.

However, considering:

- most packages install things in /usr/lib, which is already searched by default;

Quoted 4 lines

- most packages use libtool 2.4 or later,

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

Since I would prefer to avoid autoreconfiguring many packages, it would be useful to know how many packages are still using libtool versions earlier than 2.4.

Hello,

Quoted 18 lines · On Wednesday 22 March 2017 09:14:37 CET Thomas Petazzoni wrote:

Hello,

Quoted 14 lines · Arnout Vandecappelle

Quoted 1 line

So are you sure that this feature didn't appear in libtool 2.4 ?

Yeah, looks like it. E.g. speex has libtool 1.5, and it doesn't have any
sysroot support (not in configure, not in ltmain.sh).

Obviously, *this* patch is not affected by it - it certainly doesn't hurt to pass the --with-sysroot configure option. It's only patches 12+13 that we wouldn't be able to remove.

However, considering:

- most packages install things in /usr/lib, which is already searched by default;

Quoted 8 lines

Quoted 4 lines

- most packages use libtool 2.4 or later,

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

Since I would prefer to avoid autoreconfiguring many packages, it would be useful to know how many packages are still using libtool versions earlier than 2.4.

This is precisely what I wanted to known before to replying.

I extracted all (or nearly all) packages existing in Buildroot. I found 269 packages that use libool:

$ grep -ho 'VERSION="[0-9.]*' */ltmain.sh  | sort | uniq -c | sort -n
      1 VERSION="1.5.24
      1 VERSION="2.2.4
      3 VERSION="1.5.22
      5 VERSION="1.5.26
     13 VERSION="2.2.6
     29 VERSION="2.4.6
     67 VERSION="2.4.2

There 23 packages that use libtool < 2.4:
- bellagio
- celt051
- dbus-cpp
- eventlog
- gtk2-engines
- lesstif
- libargtable2
- libesmtp
- liblo
- libmhash
- libnetfilter_conntrack
- libnetfilter_log
- libnfnetlink
- libpthread-stubs
- lite
- log4cxx
- matchbox-lib
- metacity
- sdl_sound
- sylpheed
- xapp_xinput-calibrator
- xdriver_xf86-input-tslib
- xdriver_xf86-video-imx

4 of them already call autoreconf: bellagio, dbus-cpp, libnetfilter_log, libnfnetlink.

I am going to create a configuration with all of these packages.

Quoted 18 lines · J?r?me Pouiller

Hello,

Quoted 15 lines · On Wednesday 22 March 2017 09:14:37 CET Thomas Petazzoni wrote:

Hello,

Quoted 11 lines · Arnout Vandecappelle

Quoted 1 line

So are you sure that this feature didn't appear in libtool 2.4 ?

Yeah, looks like it. E.g. speex has libtool 1.5, and it doesn't have any
sysroot support (not in configure, not in ltmain.sh).

Obviously, *this* patch is not affected by it - it certainly doesn't hurt to pass the --with-sysroot configure option. It's only patches 12+13 that we wouldn't be able to remove.

However, considering:

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

- most packages install things in /usr/lib, which is already searched by default;

- most packages use libtool 2.4 or later,

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

Quoted 10 lines

Quoted 4 lines

Since I would prefer to avoid autoreconfiguring many packages, it would be useful to know how many packages are still using libtool versions earlier than 2.4.

This is precisely what I wanted to known before to replying.

I extracted all (or nearly all) packages existing in Buildroot. I found 269 packages that use libool:

Quoted 8 lines

$ grep -ho 'VERSION="[0-9.]*' */ltmain.sh  | sort | uniq -c | sort -n
      1 VERSION="1.5.24
      1 VERSION="2.2.4
      3 VERSION="1.5.22
      5 VERSION="1.5.26
     13 VERSION="2.2.6
     29 VERSION="2.4.6
     67 VERSION="2.4.2

Your command isn't good enough... It skips ltmain.sh which are not in the top
directory, and it skips the ones where VERSION isn't quoted. I got quite a few more:

$ for i in *.tar*; do tar tf $i | grep ltmain.sh | xargs -r tar -xf $i
--to-command="grep ^VERSION= | { grep -v '[^.]2\.4' && printf ' @@$i\\r'; } | tr
'\\n\\r' ' \\n'"; done

VERSION=1.5.26 @@CEGUI-0.6.2b.tar.gz VERSION="1.5.26 Debian 1.5.26-1ubuntu1" @@LiTE-0.8.10.tar.gz

VERSION=2.2.6  @@SDL-1.2.15.tar.gz
VERSION=2.2.6  @@SDL2_image-2.0.1.tar.gz
VERSION=2.2.6  @@SDL2_ttf-2.0.14.tar.gz
VERSION=2.2.6  @@SDL_image-1.2.12.tar.gz
VERSION=2.2.6  @@SDL_mixer-1.2.12.tar.gz
VERSION=2.2.6  @@SDL_net-1.2.8.tar.gz

VERSION="1.5.24 Debian 1.5.24-1ubuntu1" @@SDL_sound-1.0.3.tar.gz VERSION=2.2.6 @@SDL_ttf-2.0.11.tar.gz
VERSION="1.5.22 Debian 1.5.22-2" @@apache-log4cxx-0.10.0.tar.gz VERSION=2.2.6b @@arago-2011.09-armv5te-linux-gnueabi-sdk.tar.bz2 VERSION=2.2.6b @@arago-2011.09-armv7a-linux-gnueabi-sdk.tar.bz2 VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@argtable2-13.tar.gz VERSION=2.2.10 @@axfsutils-64886703fdff6cfc64eb20fbe7d7295bbeec867b.tar.gz VERSION=2.2.6 @@beecrypt-4.2.1.tar.gz
VERSION=2.2.6b @@bind-9.11.0-P3.tar.gz
VERSION=1.3.5 @@bind-9.11.0-P3.tar.gz

VERSION=2.2.7a  @@binutils-2.26.1.tar.bz2
VERSION=2.2.7a  @@binutils-2.27.tar.bz2
VERSION=1.5.22  @@boost_1_63_0.tar.bz2

VERSION="1.5.26 Debian 1.5.26-4" @@celt-0.5.1.3.tar.gz VERSION=1.5.22 @@clamav-0.99.2.tar.gz
VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@collectd-5.5.1.tar.bz2 VERSION="1.5.26 Debian 1.5.26-1ubuntu1" @@curlftpfs-0.9.2.tar.gz VERSION=2.2.6b @@db-5.3.28.NC.tar.gz
VERSION=2.2.6 @@db-5.3.28.NC.tar.gz
VERSION=1.5.22 @@db-5.3.28.NC.tar.gz
VERSION="2.2.6 Debian-2.2.6a-1ubuntu1" @@eventlog_0.2.12.tar.gz VERSION="1.5.22 Debian 1.5.22-4" @@faad2-2.7.tar.gz VERSION=1.4 @@fcgi-2.4.0.tar.gz

VERSION=1.5.24  @@gamin-0.1.10.tar.gz
VERSION=2.2.7a  @@gcc-4.9.4.tar.bz2
VERSION=2.2.7a  @@gcc-4.9.4.tar.bz2
VERSION=2.2.7a  @@gcc-4.9.4.tar.bz2
VERSION=1.5.16  @@gcc-4.9.4.tar.bz2
VERSION=2.2.7a  @@gcc-5.4.0.tar.bz2
VERSION=2.2.7a  @@gcc-5.4.0.tar.bz2
VERSION=2.2.7a  @@gcc-5.4.0.tar.bz2
VERSION=1.5.16  @@gcc-5.4.0.tar.bz2
VERSION=2.2.7a  @@gcc-6.2.0.tar.bz2
VERSION=2.2.7a  @@gcc-6.2.0.tar.bz2

VERSION=2.2.7a @@gcc-6.2.0.tar.bz2

VERSION=1.5.16 @@gcc-6.2.0.tar.bz2

VERSION=2.2.7a @@gdb-7.10.1.tar.xz
VERSION=2.2.7a @@gdb-7.11.1.tar.xz
VERSION="1.5.26 Debian 1.5.26-4" @@genpart-1.0.2.tar.bz2 VERSION=1.4e @@gettext-0.19.8.1.tar.xz
VERSION="2.2.6b Debian-2.2.6b-2ubuntu3" @@gmpc-11.8.16.tar.gz VERSION=2.2.6b @@google-breakpad-7515ab13768c7edc09f0f2ec2354dc6c928239a6.tar.gz VERSION="2.2.6b Debian-2.2.6b-2" @@gtk-engines-2.20.2.tar.bz2 VERSION=1.5.2 @@ijs-0.35.tar.bz2

VERSION=1.5.20  @@ipkg-0.99.163.tar.gz
VERSION=1.5.22  @@jasper-1.900.1.tar.bz2
VERSION=2.2.6b  @@json-c-0.11.tar.gz
VERSION="1.5.26 Debian 1.5.26-4"  @@kodi-16.1-Jarvis.tar.gz
VERSION=2.2.10  @@lame-3.99.5.tar.gz
VERSION=2.2.6  @@libart_lgpl-2.3.21.tar.gz
VERSION=2.2.4  @@libass-0.13.1.tar.xz
VERSION=1.5.6  @@libcdaudio-0.99.12p2.tar.gz
VERSION=2.2.6  @@libcddb-1.3.2.tar.bz2
VERSION=2.2.6  @@libdaemon-0.14.tar.gz

VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@libdbus-c++-0.9.0.tar.gz VERSION=2.2.10 @@libdmtx-0.7.4.tar.gz
VERSION=1.5.6 @@libdnet-1.11.tar.gz
VERSION="2.2.6b Debian-2.2.6b-2" @@libeXosip2-3.6.0.tar.gz VERSION="2.2.6b Debian-2.2.6b-2ubuntu3" @@libee-0.4.1.tar.gz VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@libesmtp-1.0.6.tar.bz2 VERSION=1.5.6 @@libfakekey-0.1.tar.bz2
VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@libgeotiff-1.4.0.tar.gz VERSION=1.5.26 @@libglade-2.6.4.tar.bz2
VERSION=1.5.22 @@libhid-0.2.16.tar.gz
VERSION=1.5.2 @@libid3tag-0.15.1b.tar.gz
VERSION="2.2.4 Debian-2.2.4-0ubuntu4" @@liblo-0.26.tar.gz VERSION=1.5.22 @@liblog4c-localtime-v1.0.tar.gz VERSION=1.5.2 @@libmad-0.15.1b.tar.gz
VERSION="1.5.22 Debian 1.5.22-2" @@libmatchbox-1.9.tar.bz2 VERSION=1.5.22 @@libmcrypt-2.5.8.tar.gz
VERSION="2.2.6b Debian-2.2.6b-2" @@libmnl-1.0.3.tar.bz2 VERSION="2.2.6b Debian-2.2.6b-2ubuntu3" @@libmpd-11.8.17.tar.gz

VERSION="1.5.26 Debian 1.5.26-4"  @@libmpeg2-0.5.1.tar.gz
VERSION="2.2.6b Debian-2.2.6b-2"  @@libnetfilter_conntrack-1.0.6.tar.bz2
VERSION="2.2.6b Debian-2.2.6b-2"  @@libnetfilter_log-1.0.1.tar.bz2
VERSION="2.2.6b Debian-2.2.6b-2"  @@libnetfilter_log-1.0.1.tar.bz2
VERSION="2.2.6b Debian-2.2.6b-2"  @@libnfnetlink-1.0.1.tar.bz2
VERSION="2.2.6b Debian-2.2.6b-2"  @@libosip2-3.6.0.tar.gz

VERSION="2.2.6 Debian-2.2.6a-4" @@libpthread-stubs-0.3.tar.bz2 VERSION=1.5.6 @@librsync-0.9.7.tar.gz VERSION="1.5.22 Debian 1.5.22-2" @@libsexy-0.1.11.tar.gz VERSION=1.5.14 @@libsvg-0.1.4.tar.gz
VERSION=1.5.14 @@libsvg-cairo-0.1.6.tar.gz VERSION=2.2.6 @@libtheora-1.1.1.tar.xz
VERSION=1.4.3 @@libunwind-1.1.tar.gz
VERSION=2.2.10 @@lzop-1.03.tar.gz
VERSION=1.5.2 @@madplay-0.15.2b.tar.gz
VERSION=1.5.6 @@mb-applet-startup-monitor-0.1.tar.bz2 VERSION="2.2.4 Debian-2.2.4-0ubuntu4" @@mcrypt-2.6.8.tar.gz VERSION=2.2.6b @@msgpack-0.5.4.tar.gz
VERSION=2.2.6 @@mysql-5.1.73.tar.gz
VERSION=1.5.8 @@ngrep-1.45.tar.bz2
VERSION=1.5.26 @@php-7.1.3.tar.xz
VERSION=1.5.22 @@pjproject-2.4.5.tar.bz2 VERSION=2.2.6 @@popt-1.16.tar.gz
VERSION=1.3.4 @@privoxy-3.0.26-stable-src.tar.gz VERSION="2.2.6 Debian-2.2.6a-1ubuntu1" @@proftpd-1.3.5d.tar.gz VERSION=1.5.26 @@proftpd-1.3.5d.tar.gz VERSION="2.2.6 Debian-2.2.6a-1ubuntu1" @@proftpd-1.3.5d.tar.gz VERSION=2.2.6 @@pthsem_2.0.8.tar.gz
VERSION=2.2.6 @@qt-everywhere-opensource-src-4.8.7.tar.gz VERSION=2.2.7a @@rustc-1.10.0-src.tar.gz

VERSION=1.5.6  @@sidplay-libs-2.1.1.tar.gz
VERSION=1.5.6  @@sidplay-libs-2.1.1.tar.gz
VERSION=1.5.6  @@sidplay-libs-2.1.1.tar.gz

VERSION=1.4 @@sidplay-libs-2.1.1.tar.gz
VERSION=1.5.6 @@sidplay-libs-2.1.1.tar.gz
VERSION=1.5.6 @@sidplay-libs-2.1.1.tar.gz VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@sofia-sip-1.12.11.tar.gz VERSION="1.5.22 Debian 1.5.22-4" @@speex-1.2rc1.tar.gz VERSION=2.2.6 @@sqlcipher-v3.2.0.tar.gz
VERSION=1.5.6 @@startup-notification-0.9.tar.gz

VERSION=1.5.22  @@sysfsutils-2.1.0.tar.gz
VERSION=1.5.22  @@szip-2.1.tar.gz
VERSION=1.5.24  @@tn5250-0.17.4.tar.gz

VERSION=1.5.6 @@ucl-1.03.tar.gz
VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@unixODBC-2.3.2.tar.gz VERSION="2.2.6 Debian-2.2.6a-4" @@vorbis-tools-1.4.0.tar.gz VERSION=1.4.3 @@xcursor-transparent-theme-0.1.1.tar.gz VERSION="1.5.26 Debian 1.5.26-4" @@xf86-input-tslib-0.0.6.tar.bz2 VERSION="2.2.6b Debian-2.2.6b-2ubuntu1" @@xinput_calibrator-0.7.5.tar.gz

That's 109 tarballs with some older libtool.

Note that this just iterates over the tarballs that I have in my download
directory, there may be some old versions of packages in there. Anyway, I think 109 out of the 2150 tarballs in that directory is still extremely small.

Note also that in many of these, the ltmain will be in some subdirectory
containing bundled source that we don't even use.

Note, finally, that there are also quite a few host-only packages in there
(e.g. gcc, but that one is special because it also builds stuff for the target. It doesn't seem to install .la files, however).

Quoted 25 lines

There 23 packages that use libtool < 2.4:
- bellagio
- celt051
- dbus-cpp
- eventlog
- gtk2-engines
- lesstif
- libargtable2
- libesmtp
- liblo
- libmhash
- libnetfilter_conntrack
- libnetfilter_log
- libnfnetlink
- libpthread-stubs
- lite
- log4cxx
- matchbox-lib
- metacity
- sdl_sound
- sylpheed
- xapp_xinput-calibrator
- xdriver_xf86-input-tslib
- xdriver_xf86-video-imx

Quoted 4 lines

4 of them already call autoreconf: bellagio, dbus-cpp, libnetfilter_log, libnfnetlink.

I am going to create a configuration with all of these packages.

That's not necessarily sufficient: the generated .la file could be wrong, so
you have to check if packages that use it are still working correctly. Alternatively, just check all the .la files.

Regards,
Arnout

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I think we can take the risk. The autobuilders will discover any issues, which we can fix per package (e.g. with AUTORECONF = YES).

By the way, this series also *fixes* issues. E.g. I couldn't reproduce
http://autobuild.buildroot.net/results/e8c6bdc314b9a8d5de303633a3abd7b7e44beb2e
after applying this series, whereas I could reproduce it before.

Quoted 1 line · J?r?me Pouiller

libtool include support for cross-compilation since v1.5.

Are you sure this is true?

In the release notes of libtool v2.4
(https://savannah.gnu.org/forum/forum.php?forum_id=6525), I see:

Since $lt_sysroot' is now correctly filled, it is no more necessary to patch .la' files. Indeed, if $libdir point to /usr/lib', libtool will also search in $(lt_sysroot)/usr/lib'

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/pkg-generic.mk | 11 -----------
 1 file changed, 11 deletions(-)

package/pkg-generic.mk +0 -11

index 827de62..5d12ac3 100644
@@ -268,17 +268,6 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 				-e "s, at BASE_DIR@,$(BASE_DIR),g" \
 				$(addprefix $(STAGING_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ;\
 	fi
-	@$(call MESSAGE,"Fixing libtool files")
-	$(Q)find $(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
-		$(SED) "s:$(BASE_DIR):@BASE_DIR@:g" \
-			-e "s:$(STAGING_DIR):@STAGING_DIR@:g" \
-			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-				-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
-			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
-			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
-			-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
-			-e "s:@BASE_DIR@:$(BASE_DIR):g"
 	@$(call step_end,install-staging)
 	$(Q)touch $@
 

Hi Jerome,

Quoted 3 lines · J?r?me Pouiller

Since $lt_sysroot' is now correctly filled, it is no more necessary to patch .la' files. Indeed, if $libdir point to /usr/lib', libtool will also search in $(lt_sysroot)/usr/lib'

Unfortunately, not all packages that use libtool also use automake.

So some packages may die because of this.

That said, we should probably just fix these individual packages.

Hello Anrout,

Quoted 2 lines · On Saturday 18 March 2017 16:37:31 CET Arnout Vandecappelle wrote:

Hi Jerome,

Quoted 6 lines · J?r?me Pouiller

Quoted 3 lines

Since $lt_sysroot' is now correctly filled, it is no more necessary to patch .la' files. Indeed, if $libdir point to /usr/lib', libtool will also search in $(lt_sysroot)/usr/lib'

Unfortunately, not all packages that use libtool also use automake.

You mean autoconf? Do you have an example of this?

Quoted 4 lines

So some packages may die because of this.

That said, we should probably just fix these individual packages.

yes, I think it very unusual.

Since $lt_sysroot' is now correctly filled, it is no more necessary to patch .la' files. Indeed, if $libdir point to `/usr/lib', libtool will also search

in `$(lt_sysroot)/usr/lib'

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/pkg-generic.mk | 11 -----------
 1 file changed, 11 deletions(-)

package/pkg-generic.mk +0 -11

index 827de62..5d12ac3 100644
@@ -268,17 +268,6 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 				-e "s, at BASE_DIR@,$(BASE_DIR),g" \
 				$(addprefix $(STAGING_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ;\
 	fi
-	@$(call MESSAGE,"Fixing libtool files")
-	$(Q)find $(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
-		$(SED) "s:$(BASE_DIR):@BASE_DIR@:g" \
-			-e "s:$(STAGING_DIR):@STAGING_DIR@:g" \
-			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-				-e "s:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
-			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
-			$(if $(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
-				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
-			-e "s:@STAGING_DIR@:$(STAGING_DIR):g" \
-			-e "s:@BASE_DIR@:$(BASE_DIR):g"
 	@$(call step_end,install-staging)
 	$(Q)touch $@
 

Until now Builroot patched libtool in order to ignore `$libdir' provided by .la

file. It used the path where it found the .la instead of $libdir'. However, since v1.5 libtool correctly prepend sysroot to $libdir' as we can see a few

lines below patched lines:

  func_append newdependency_libs " ${lt_sysroot:+=}$libdir/$name"

(in fact, this line just prepend '=', and '=' is substituted later)

Signed-off-by J?r?me Pouiller <[email protected]>

---
 support/libtool/buildroot-libtool-v1.5.patch   | 32 ++------------------------
 support/libtool/buildroot-libtool-v2.2.patch   | 30 +-----------------------
 support/libtool/buildroot-libtool-v2.4.4.patch | 11 ---------
 support/libtool/buildroot-libtool-v2.4.patch   | 11 ---------
 4 files changed, 3 insertions(+), 81 deletions(-)

support/libtool/buildroot-libtool-v1.5.patch +2 -30

index cdd9c5a..609006a 100644
@@ -34,24 +34,7 @@
  	if test -n "$link_static_flag"; then
  	  compile_command="$compile_command $link_static_flag"
  	  finalize_command="$finalize_command $link_static_flag"
-@@ -2146,8 +2153,14 @@
- 	    absdir="$abs_ladir"
- 	    libdir="$abs_ladir"
- 	  else
--	    dir="$libdir"
--	    absdir="$libdir"
-+            # Adding 'libdir' from the .la file to our library search paths
-+            # breaks crosscompilation horribly.  We cheat here and don't add
-+            # it, instead adding the path where we found the .la.  -CL
-+	    dir="$abs_ladir"
-+	    absdir="$abs_ladir"
-+	    libdir="$abs_ladir"
-+	    #dir="$libdir"
-+	    #absdir="$libdir"
- 	  fi
- 	else
- 	  dir="$ladir/$objdir"
-@@ -2272,7 +2285,7 @@
+@@ -2272,7 +2279,7 @@
  	   { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
  	  if test "$installed" = no; then
  	    notinst_deplibs="$notinst_deplibs $lib"

@@ -60,18 +43,7 @@
  	  fi
  	  # This is a shared library
 
-@@ -5169,6 +5182,10 @@
- 	    # Replace all uninstalled libtool libraries with the installed ones
- 	    newdependency_libs=
- 	    for deplib in $dependency_libs; do
-+              # Replacing uninstalled with installed can easily break crosscompilation,
-+              # since the installed path is generally the wrong architecture.  -CL
-+              newdependency_libs="$newdependency_libs $deplib"
-+              continue
- 	      case $deplib in
- 	      *.la)
- 		name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`
-@@ -5487,10 +5504,13 @@
+@@ -5487,10 +5494,13 @@
  	  # At present, this check doesn't affect windows .dll's that
  	  # are installed into $libdir/../bin (currently, that works fine)
  	  # but it's something to keep an eye on.

support/libtool/buildroot-libtool-v2.2.patch +1 -29

index 8bb7826..3af0604 100644
@@ -67,24 +67,7 @@
  	# The effects of -static are defined in a previous loop.
  	# We used to do the same as -all-static on platforms that
  	# didn't have a PIC flag, but the assumption that the effects
-@@ -5739,8 +5738,14 @@
- 	    absdir="$abs_ladir"
- 	    libdir="$abs_ladir"
- 	  else
--	    dir="$libdir"
--	    absdir="$libdir"
-+            # Adding 'libdir' from the .la file to our library search paths
-+            # breaks crosscompilation horribly.  We cheat here and don't add
-+            # it, instead adding the path where we found the .la.  -CL
-+	    dir="$abs_ladir"
-+	    absdir="$abs_ladir"
-+	    libdir="$abs_ladir"
-+	    #dir="$libdir"
-+	    #absdir="$libdir"
- 	  fi
- 	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
- 	else
-@@ -5891,7 +5896,7 @@
+@@ -5891,7 +5890,7 @@
  	  *)
  	    if test "$installed" = no; then
  	      notinst_deplibs="$notinst_deplibs $lib"

@@ -93,14 +76,3 @@
  	    fi
  	    ;;
  	  esac
-@@ -8373,6 +8378,10 @@
- 	    # Replace all uninstalled libtool libraries with the installed ones
- 	    newdependency_libs=
- 	    for deplib in $dependency_libs; do
-+              # Replacing uninstalled with installed can easily break crosscompilation,
-+              # since the installed path is generally the wrong architecture.  -CL
-+              newdependency_libs="$newdependency_libs $deplib"
-+              continue
- 	      case $deplib in
- 	      *.la)
- 		func_basename "$deplib"

support/libtool/buildroot-libtool-v2.4.4.patch +0 -11

index bcdf30c..d71669b 100644
@@ -82,14 +82,3 @@ Signed-off-by: Gustavo Zacarias <[email protected]>
  	    fi
  	    ;;
  	  esac
-@@ -10710,6 +10710,10 @@
- 	    # Replace all uninstalled libtool libraries with the installed ones
- 	    newdependency_libs=
- 	    for deplib in $dependency_libs; do
-+	      # Replacing uninstalled with installed can easily break crosscompilation,
-+	      # since the installed path is generally the wrong architecture.  -CL
-+	      newdependency_libs="$newdependency_libs $deplib"
-+	      continue
- 	      case $deplib in
- 	      *.la)
- 		func_basename "$deplib"

support/libtool/buildroot-libtool-v2.4.patch +0 -11

index f610b1b..bf40c94 100644
@@ -76,14 +76,3 @@
  	    fi
  	    ;;
  	  esac
-@@ -9275,6 +9274,10 @@
- 	    # Replace all uninstalled libtool libraries with the installed ones
- 	    newdependency_libs=
- 	    for deplib in $dependency_libs; do
-+              # Replacing uninstalled with installed can easily break crosscompilation,
-+              # since the installed path is generally the wrong architecture.  -CL
-+              newdependency_libs="$newdependency_libs $deplib"
-+              continue
- 	      case $deplib in
- 	      *.la)
- 		func_basename "$deplib"

When it compute list of directories to include in link, libtool has a

conservative behavior. It add `$inst_prefix_dir$libdir' but also keep original

`$libdir'. Thus, it call:

-L/usr/lib -L/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib

It works since the last path has priority. However, toolchan-wrapper consider

`/usr/lib' an an unsafe path.

This patch remove original `$libdir'.

Since last versions of binutils provide `-Wpoison-system-directories' option, I think it make sense to try to upstream this patch.

Note Yocto has a similar patch:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/use-sysroot-in-libpath.patch

Signed-off-by J?r?me Pouiller <[email protected]>

---
 support/libtool/buildroot-libtool-v1.5.patch   | 18 ++++++++++++++++++
 support/libtool/buildroot-libtool-v2.2.patch   | 18 ++++++++++++++++++
 support/libtool/buildroot-libtool-v2.4.4.patch |  9 +++++++++
 support/libtool/buildroot-libtool-v2.4.patch   |  9 +++++++++
 4 files changed, 54 insertions(+)

support/libtool/buildroot-libtool-v1.5.patch +18 -0

index 609006a..51d049f 100644
@@ -43,6 +43,24 @@
  	  fi
  	  # This is a shared library
 
+@@ -2412,7 +2419,7 @@
+ 		if test -n "$inst_prefix_dir"; then
+ 		  case "$libdir" in
+ 		    [\\/]*)
+-		      add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		      add_dir="-L$inst_prefix_dir$libdir"
+ 		      ;;
+ 		  esac
+ 		fi
+@@ -2492,7 +2499,7 @@
+ 	      if test -n "$inst_prefix_dir"; then
+ 		case "$libdir" in
+ 		  [\\/]*)
+-		    add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		    add_dir="-L$inst_prefix_dir$libdir"
+ 		    ;;
+ 		esac
+ 	      fi
 @@ -5487,10 +5494,13 @@
  	  # At present, this check doesn't affect windows .dll's that
  	  # are installed into $libdir/../bin (currently, that works fine)

support/libtool/buildroot-libtool-v2.2.patch +18 -0

index 3af0604..be4e5e3 100644
@@ -76,3 +76,21 @@
  	    fi
  	    ;;
  	  esac
+@@ -6094,7 +6093,7 @@
+ 		if test -n "$inst_prefix_dir"; then
+ 		  case $libdir in
+ 		    [\\/]*)
+-		      add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		      add_dir="-L$inst_prefix_dir$libdir"
+ 		      ;;
+ 		  esac
+ 		fi
+@@ -6167,7 +6166,7 @@
+ 	      if test -n "$inst_prefix_dir"; then
+ 		case $libdir in
+ 		  [\\/]*)
+-		    add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		    add_dir="-L$inst_prefix_dir$libdir"
+ 		    ;;
+ 		esac
+ 	      fi

support/libtool/buildroot-libtool-v2.4.4.patch +9 -0

index d71669b..1458b5e 100644
@@ -82,3 +82,12 @@ Signed-off-by: Gustavo Zacarias <[email protected]>
  	    fi
  	    ;;
  	  esac
+@@ -8854,7 +8854,7 @@
+ 	      if test -n "$inst_prefix_dir"; then
+ 		case $libdir in
+ 		  [\\/]*)
+-		    func_append add_dir " -L$inst_prefix_dir$libdir"
++		    add_dir="-L$inst_prefix_dir$libdir"
+ 		    ;;
+ 		esac
+ 	      fi

support/libtool/buildroot-libtool-v2.4.patch +9 -0

index bf40c94..c2edd99 100644
@@ -76,3 +76,12 @@
  	    fi
  	    ;;
  	  esac
+@@ -8854,7 +8854,7 @@
+ 	      if test -n "$inst_prefix_dir"; then
+ 		case $libdir in
+ 		  [\\/]*)
+-		    func_append add_dir " -L$inst_prefix_dir$libdir"
++		    add_dir="-L$inst_prefix_dir$libdir"
+ 		    ;;
+ 		esac
+ 	      fi

Until now, libtool was not configured for cross-compilation. It did works,

because Buildroot patched $libdir in .la files to include directories from sysroot. However, this was done after package installation. Thus, a package was not able to use its own (not yet patched) .la files. Because of that, libtool was not able to relink binaries during installation. So, Buildroot disabled relink on installation. Consequently, binaries that depends on internal

libraries contains their build path in their RPATH:

  $ readelf -d target/bin/mount | grep RPATH
  0x0000000f (RPATH)  Library rpath: [/home/buildbot/output/build/util-linux-2.27.1/.libs]

This particularity was incompatible with creation of reproducible binaries.

However, with previous changes, libtool is now correctly configured and binaries can be relinked on install. So we can re-enable this feature.

Note Yocto have a patch that remove extra paths during compilation and make relink unnecessary:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fixinstall.patch

Signed-off-by J?r?me Pouiller <[email protected]>

---
 support/libtool/buildroot-libtool-v1.5.patch   | 9 ---------
 support/libtool/buildroot-libtool-v2.2.patch   | 9 ---------
 support/libtool/buildroot-libtool-v2.4.4.patch | 9 ---------
 support/libtool/buildroot-libtool-v2.4.patch   | 9 ---------
 4 files changed, 36 deletions(-)

When installing binaries to $TARGET_DIR, libtool add `$STAGING_DIR{,/usr}/lib' to RPATH. This is annoying to create reproducible binaries. This patch just inform libtool that these paths are reachable on runtime and it is necessary to

add then to RPATH.

Notice $lt_cv_sys_lib_dlsearch_path_spec' was introduced in libtool v2.0. Packages with libtool v1.5 continue to include $STAGING_DIR{,/usr}/lib' in their RPATH. The few packages that use libtool v1.5 have to be patched individually in order to make them reproducible (adding AUTORECONF=YES should be sufficient in most cases).

Note, instead of providing $lt_cv_sys_lib_dlsearch_path_spec, Yocto patch libtool:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fix-final-rpath.patch

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

package/Makefile.in +1 -1

index 688d5b1..6a341f2 100644
@@ -355,6 +355,7 @@ TARGET_CONFIGURE_ARGS = \
        ac_cv_func_calloc_0_nonnull=yes \
        ac_cv_func_realloc_0_nonnull=yes \
        lt_cv_sys_lib_search_path_spec="" \
+       lt_cv_sys_lib_dlsearch_path_spec="/lib /usr/lib $(STAGING_DIR)/lib $(STAGING_DIR)/usr/lib" \
        $(BR2_AC_CV_C_BIGENDIAN) \
        $(BR2_GT_CV_FUNC_GNUGETTEXT_LIBC)
 
--

1.9.1

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

When installing binaries to $TARGET_DIR, libtool add `$STAGING_DIR{,/usr}/lib'

to RPATH. This is annoying to create reproducible binaries. This patch just inform libtool that these paths are reachable on runtime and it is necessary to

add then to RPATH.

Notice $lt_cv_sys_lib_dlsearch_path_spec' was introduced in libtool v2.0. Packages with libtool v1.5 continue to include $STAGING_DIR{,/usr}/lib' in their RPATH. The few packages that use libtool v1.5 have to be patched individually in order to make them reproducible (adding AUTORECONF=YES should be sufficient in most cases).

Note, instead of providing $lt_cv_sys_lib_dlsearch_path_spec, Yocto patch libtool:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fix-final-rpath.patch

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/Makefile.in | 1 +
 1 file changed, 1 insertion(+)

package/Makefile.in +1 -0

index 688d5b1..6a341f2 100644
@@ -355,6 +355,7 @@ TARGET_CONFIGURE_ARGS = \
 	ac_cv_func_calloc_0_nonnull=yes \
 	ac_cv_func_realloc_0_nonnull=yes \
 	lt_cv_sys_lib_search_path_spec="" \
+	lt_cv_sys_lib_dlsearch_path_spec="/lib /usr/lib $(STAGING_DIR)/lib $(STAGING_DIR)/usr/lib" \
 	$(BR2_AC_CV_C_BIGENDIAN) \
 	$(BR2_GT_CV_FUNC_GNUGETTEXT_LIBC)
 

During install, libtool check if $libdir is a subdirectory of $DESTDIR. Until

now $DESTDIR was $(TARGET_DIR) and $libdir was $(STAGING_DIR)/usr/lib. Consequently, this test failed. Since $libdir is now /usr/lib, there is not more

reason to skipped that test.

Signed-off-by J?r?me Pouiller <[email protected]>

---
 support/libtool/buildroot-libtool-v1.5.patch   | 18 ------------------
 support/libtool/buildroot-libtool-v2.2.patch   | 26 ++++++--------------------
 support/libtool/buildroot-libtool-v2.4.4.patch | 25 +++++--------------------
 support/libtool/buildroot-libtool-v2.4.patch   | 24 +++++-------------------
 4 files changed, 16 insertions(+), 77 deletions(-)

Buildroot included a work around for the case libtool was called with a non-existant `--tag'. We was not able create reproduce this problem anymore. So, we drop this workaround.

Please send a bug report if you encounter this problem again.

Signed-off-by J?r?me Pouiller <[email protected]>

---
 support/libtool/buildroot-libtool-v1.5.patch   | 12 ------------
 support/libtool/buildroot-libtool-v2.2.patch   | 11 -----------
 support/libtool/buildroot-libtool-v2.4.4.patch | 11 -----------
 support/libtool/buildroot-libtool-v2.4.patch   | 11 -----------
 4 files changed, 45 deletions(-)

Commit 6246704008 forced $sys_lib_search_path_spec to be empty. Commit log said that it was filled with native paths. However, recent tests show that $sys_lib_search_path_spec is correctly filled with result of
`$CC -print-search-dirs' as it should.

So this patch remove this workaround.

Signed-off-by J?r?me Pouiller <[email protected]>

---
 package/Makefile.in | 1 -
 1 file changed, 1 deletion(-)

package/Makefile.in +0 -1

index 6a341f2..ee43985 100644
@@ -354,7 +354,6 @@ TARGET_CONFIGURE_ARGS = \
 	ac_cv_func_malloc_0_nonnull=yes \
 	ac_cv_func_calloc_0_nonnull=yes \
 	ac_cv_func_realloc_0_nonnull=yes \
-	lt_cv_sys_lib_search_path_spec="" \
 	lt_cv_sys_lib_dlsearch_path_spec="/lib /usr/lib $(STAGING_DIR)/lib $(STAGING_DIR)/usr/lib" \
 	$(BR2_AC_CV_C_BIGENDIAN) \
 	$(BR2_GT_CV_FUNC_GNUGETTEXT_LIBC)

Patches 11 to 19 are nearly a series in the series. Until now, most of binaries installed by libtool was configured with RPATH pointingto their build directory. Indeed, libtool add this path during compilation in order to be able to execute them directly from build directory. This path should normally removed during install, but Buildroot disable this behavior (patch 15). Simply re-enabling this behavior does not work. Indeed, during relink, libtool try to use .la that are not yet patched and fail to find libraries. On another side, libtool support usage of a sysroot since v1.5. To enable this support, we have to keep original values from .la file (patch 12 and 13) and inform libtool we are using a sysroot (patch 11).

Patch 14 fix a small incompatibility with unsafe path detection.

Since libtool is now correctly used, it is not more necessary to disable install directory sanity check (patch 17).

From libtool point of view, sysroot is not reachable from $(TARGET_DIR). So, during installation to $(TARGET_DIR), it add an entry in RPATH that point to $(STAGING_DIR). To fix this problem, we just have to inform libtool that $(STAGING_DIR) is reachable (patch 16).

Finally, I also clean up libtool infra from modification that seems useless now (patches 18 and 19).

I tested this series using internal toolchain and Linaro toolchain with these packages:

BR2_INIT_SYSTEMD=y (install public libraries in /usr/lib/systemd)
BR2_PACKAGE_LIBCDAUDIO=y (libtool 1.5)
BR2_PACKAGE_LIBLO=y (libtool 2.2)
BR2_PACKAGE_MADPLAY=y (unpatched libtool)
BR2_PACKAGE_ALSA_LIB=y (optional dependency to Madplay)
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_PY_PYC=y
BR2_PACKAGE_GNUPG2=y

Except patches 12 and 13, I think whole series is bisectable.

Hello,

On Tuesday 20 December 2016 14:46:17 CET J?r?me Pouiller wrote:
[...]

Quoted 36 lines

Patches 11 to 19 are nearly a series in the series. Until now, most of binaries installed by libtool was configured with RPATH pointingto their build directory. Indeed, libtool add this path during compilation in order to be able to execute them directly from build directory. This path should normally removed during install, but Buildroot disable this behavior (patch 15). Simply re-enabling this behavior does not work. Indeed, during relink, libtool try to use .la that are not yet patched and fail to find libraries. On another side, libtool support usage of a sysroot since v1.5. To enable this support, we have to keep original values from .la file (patch 12 and 13) and inform libtool we are using a sysroot (patch 11).

Patch 14 fix a small incompatibility with unsafe path detection.

Since libtool is now correctly used, it is not more necessary to disable install directory sanity check (patch 17).

From libtool point of view, sysroot is not reachable from $(TARGET_DIR). So, during installation to $(TARGET_DIR), it add an entry in RPATH that point to $(STAGING_DIR). To fix this problem, we just have to inform libtool that $(STAGING_DIR) is reachable (patch 16).

Finally, I also clean up libtool infra from modification that seems useless now (patches 18 and 19).

I tested this series using internal toolchain and Linaro toolchain with these packages:

BR2_INIT_SYSTEMD=y (install public libraries in /usr/lib/systemd)
BR2_PACKAGE_LIBCDAUDIO=y (libtool 1.5)
BR2_PACKAGE_LIBLO=y (libtool 2.2)
BR2_PACKAGE_MADPLAY=y (unpatched libtool)
BR2_PACKAGE_ALSA_LIB=y (optional dependency to Madplay)
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_PYTHON_PY_PYC=y
BR2_PACKAGE_GNUPG2=y

Quoted 1 line

Except patches 12 and 13, I think whole series is bisectable.

[...]

As I said above, patches 11 to 19 of this series do a strong clean up of libtool infrastructure. I think these patches are important for two reasons:

1. It is the best way to support reproducible build from different build paths
2. Currently BR usage of libtool is not standard. These patches use libtool in the right way. It drop unnecessary RPATH from binaries. It drop most of patches applied to libtool.

However, this series do very intrusive changes and it is difficult to review. Consequently, I think it is necessary to apply them very early in a development cycle. So, I suggest to apply them to 'next' now.