[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello,

this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
relocatable. It sanitizes the RPATH of all ELF files in the "target"
and "host" tree using "patchelf --make-rpath-relative". I have started
the mainlining process implementing "--make-rpath-relative" using
GitHub pull request [1]... till now, no answer!

Furthermore this patch creates the script "relocate-sdk.sh" in the top
directory of the "host" tree allowing to relocate the SDK after it has
been moved to a new location. It replaces the old path with the new
one in all text files identified by "file --mime-type". The location
is stored in "usr/share/buildroot/sdk-location".

Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
libraries. To overcome this problem, "qt5pase" now creates "qt.conf".

Other Questions:

- Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
  files in the target tree. "/lib" and "/usr/lib" have been removed
  already. 

Things not yet addressed:

- "make toolchain" creates a toolchain tree which still has references
  to the build system (in ELF and text files).  

Changes since v2:

- provide "qt.conf" to make "qmake" relocatable
- sed now uses the separator "\" to substitute the directory path.
  It's one of the few characters not allowed in file names. To
  avoid interpreting it as escape character, the "read -r" is used.
- The paranoia substituion check is done before doing the real
  substituion.

Changes since v1:

- The name SDK has been chosen for the relocatabed "HOST_DIR" (instead
  of toolchanin).
- The patchelf version bump and patching are now done by 2 patches
- No more helper functions are used in the Makefile to call "fix-rpath"
  but added directly.
- The staging tree is not touched any more... until we have a good
  reason to do so. 
- The sanitation is now performed by an optimized "fix-rpath" script.
- The relocate-sdk script is now copied for support/misc to the
  top directory of the host tree.

[1] https://github.com/NixOS/patchelf/pull/118

Samuel Martin (1):
  support/scripts: add fix-rpath script to sanitize the rpath

Wolfgang Grandegger (9):
  package/patchelf: use most recent version as a base for rpath
    sanitation
  package/patchelf: add patch for rpath sanitation under a root
    directory
  core: sanitize RPATH in host tree at the very end of the build
  core: sanitize RPATH in target tree at the end of the target
    finalization
  support/scripts: add reloacte-sdk.sh script for SDK relocation
  core: install relocation script and location at the end of the build
  external-toolchain: check if a buildroot SDK has already been
    relocated
  support/scripts: check-host-rpath now handles $ORIGIN as well
  package/qt5base: provide "qt.conf" to make "qmake" relocatable

 Makefile                                           |  10 +
 ...to-make-the-rpath-relative-under-a-specif.patch | 315 +++++++++++++++++++++
 package/patchelf/patchelf.hash                     |   2 +-
 package/patchelf/patchelf.mk                       |   6 +-
 package/qt5/qt5base/qt.conf.in                     |   6 +
 package/qt5/qt5base/qt5base.mk                     |   8 +
 support/misc/relocate-sdk.sh                       |  47 +++
 support/scripts/check-host-rpath                   |   2 +-
 support/scripts/fix-rpath                          | 103 +++++++
 toolchain/helpers.mk                               |  15 +
 .../toolchain-external/pkg-toolchain-external.mk   |   1 +
 11 files changed, 510 insertions(+), 5 deletions(-)
 create mode 100644 package/patchelf/0001-Add-option-to-make-the-rpath-relative-under-a-specif.patch
 create mode 100644 package/qt5/qt5base/qt.conf.in
 create mode 100755 support/misc/relocate-sdk.sh
 create mode 100755 support/scripts/fix-rpath

-- 
1.9.1

[Buildroot] [RFC PATCH v3 01/10] package/patchelf: use most recent version as a base for rpath sanitation

[Wolfgang Grandegger]

We would like to use "patchelf" to do rpath sanitation of all ELF files
in the "host" and "target" directory, mainly because a script based
solutions is to complex and slow.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 package/patchelf/patchelf.hash | 2 +-
 package/patchelf/patchelf.mk   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/patchelf/patchelf.hash b/package/patchelf/patchelf.hash
index 653eb46..ba620d4 100644
--- a/package/patchelf/patchelf.hash
+++ b/package/patchelf/patchelf.hash
@@ -1,2 +1,2 @@
 # Locally calculated
-sha256	a0f65c1ba148890e9f2f7823f4bedf7ecad5417772f64f994004f59a39014f83	patchelf-0.9.tar.bz2
+sha256  d90cbedb2efa516b2373640560aa6b37f0e29c4967611c3312981e30dbbab966  patchelf-c1f89c077e44a495c62ed0dcfaeca21510df93ef.tar.gz
diff --git a/package/patchelf/patchelf.mk b/package/patchelf/patchelf.mk
index cf2e43a..c880222 100644
--- a/package/patchelf/patchelf.mk
+++ b/package/patchelf/patchelf.mk
@@ -4,9 +4,9 @@
 #
 ################################################################################
 
-PATCHELF_VERSION = 0.9
-PATCHELF_SITE = http://releases.nixos.org/patchelf/patchelf-$(PATCHELF_VERSION)
-PATCHELF_SOURCE = patchelf-$(PATCHELF_VERSION).tar.bz2
+PATCHELF_VERSION = c1f89c077e44a495c62ed0dcfaeca21510df93ef
+PATCHELF_SITE = $(call github,NixOS,patchelf,$(PATCHELF_VERSION))
+PATCHELF_AUTORECONF = YES
 PATCHELF_LICENSE = GPLv3+
 PATCHELF_LICENSE_FILES = COPYING
 
-- 
1.9.1

[Buildroot] [RFC PATCH v3 02/10] package/patchelf: add patch for rpath sanitation under a root directory

[Wolfgang Grandegger]

The patch allows to use patchelf to sanitize the rpath of the buildroot
libraries and binaries using the option "--make-rpath-rleative <rootdir>".

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 ...to-make-the-rpath-relative-under-a-specif.patch | 315 +++++++++++++++++++++
 1 file changed, 315 insertions(+)
 create mode 100644 package/patchelf/0001-Add-option-to-make-the-rpath-relative-under-a-specif.patch

diff --git a/package/patchelf/0001-Add-option-to-make-the-rpath-relative-under-a-specif.patch b/package/patchelf/0001-Add-option-to-make-the-rpath-relative-under-a-specif.patch
new file mode 100644
index 0000000..25ecaa6
--- /dev/null
+++ b/package/patchelf/0001-Add-option-to-make-the-rpath-relative-under-a-specif.patch
@@ -0,0 +1,315 @@
+From 917df18ac4249116948d39e1217008a43861f1b5 Mon Sep 17 00:00:00 2001
+From: Wolfgang Grandegger <wg@grandegger.com>
+Date: Mon, 20 Feb 2017 16:29:24 +0100
+Subject: [PATCH] Add option to make the rpath relative under a specified root
+ directory
+
+Running "patchelf" with the option "--make-rpath-relative ROOTDIR" will
+modify or delete the RPATHDIRs according the following rules
+similar to Martin's patches [1] making the Buildroot toolchaing/SDK
+relocatable.
+
+RPATHDIR starts with "$ORIGIN":
+    The original build-system already took care of setting a relative
+    RPATH, resolve it and test if it's valid (does exist)
+
+RPATHDIR starts with ROOTDIR:
+    The original build-system added some absolute RPATH (absolute on
+    the build machine). Test if it's valid (does exist).
+
+ROOTDIR/RPATHDIR exists:
+    The original build-system already took care of setting an absolute
+    RPATH (absolute in the final rootfs), resolve it and test if it's
+    valid (does exist).
+
+RPATHDIR points somewhere else:
+    (can be anywhere: build trees, staging tree, host location,
+    non-existing location, etc.). Just discard such a path.
+
+In addition, the option "--no-standard-libs" will discard RPATHDIRs
+ROOTDIR/lib and ROOTDIR/usr/lib. Like "--shrink-rpath", RPATHDIRs
+are also discarded if the directories do not contain a library
+referenced by the DT_NEEDED fields.
+
+[1] http://lists.busybox.net/pipermail/buildroot/2016-April/159422.html
+
+Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
+---
+ src/patchelf.cc | 179 ++++++++++++++++++++++++++++++++++++++++++++++++--------
+ 1 file changed, 153 insertions(+), 26 deletions(-)
+
+diff --git a/src/patchelf.cc b/src/patchelf.cc
+index 5077cd5..99e6915 100644
+--- a/src/patchelf.cc
++++ b/src/patchelf.cc
+@@ -49,6 +49,8 @@ static int pageSize = PAGESIZE;
+ 
+ typedef std::shared_ptr<std::vector<unsigned char>> FileContents;
+ 
++#define MODIFY_FLAG_NO_STD_LIB_DIRS 0x1
++static int modifyFlags;
+ 
+ #define ElfFileParams class Elf_Ehdr, class Elf_Phdr, class Elf_Shdr, class Elf_Addr, class Elf_Off, class Elf_Dyn, class Elf_Sym, class Elf_Verneed
+ #define ElfFileParamNames Elf_Ehdr, Elf_Phdr, Elf_Shdr, Elf_Addr, Elf_Off, Elf_Dyn, Elf_Sym, Elf_Verneed
+@@ -83,6 +85,36 @@ static unsigned int getPageSize()
+     return pageSize;
+ }
+ 
++static bool absolutePathExists(const std::string & path, std::string & canonicalPath)
++{
++    char *cpath = realpath(path.c_str(), NULL);
++    if (cpath) {
++        canonicalPath = cpath;
++        free(cpath);
++        return true;
++    } else {
++        return false;
++    }
++}
++
++static std::string makePathRelative(const std::string & path,
++    const std::string & refPath, const std::string & rootDir)
++{
++    std::string relPath = "$ORIGIN";
++
++    /* Strip root path first */
++    std::string p = path.substr(rootDir.length());
++    std::string refP = refPath.substr(rootDir.length());
++
++    std::size_t pos = refP.find_first_of('/');
++    while (pos != std::string::npos) {
++        pos =refP.find_first_of('/', pos + 1);
++        relPath.append("/..");
++    }
++    relPath.append(p);
++
++    return relPath;
++}
+ 
+ template<ElfFileParams>
+ class ElfFile
+@@ -191,9 +223,14 @@ public:
+ 
+     void setInterpreter(const std::string & newInterpreter);
+ 
+-    typedef enum { rpPrint, rpShrink, rpSet, rpRemove } RPathOp;
++    typedef enum { rpPrint, rpShrink, rpMakeRelative, rpSet, rpRemove} RPathOp;
++
++    bool libFoundInRPath(const std::string & dirName,
++                         const std::vector<std::string> neededLibs);
+ 
+-    void modifyRPath(RPathOp op, const std::vector<std::string> & allowedRpathPrefixes, std::string newRPath);
++    void modifyRPath(RPathOp op,
++                     const std::vector<std::string> & allowedRpathPrefixes,
++                     std::string rootDir, int flags, std::string newRPath);
+ 
+     void addNeeded(const std::set<std::string> & libs);
+ 
+@@ -1099,10 +1136,35 @@ static void concatToRPath(std::string & rpath, const std::string & path)
+     rpath += path;
+ }
+ 
++template<ElfFileParams>
++bool ElfFile<ElfFileParamNames>::libFoundInRPath(const std::string & dirName,
++    const std::vector<std::string> neededLibs)
++{
++    std::vector<bool> neededLibFound(neededLibs.size(), false);
++
++    /* For each library that we haven't found yet, see if it
++       exists in this directory. */
++    bool libFound = false;
++    for (unsigned int j = 0; j < neededLibs.size(); ++j)
++        if (!neededLibFound[j]) {
++            std::string libName = dirName + "/" + neededLibs[j];
++            try {
++                if (getElfType(readFile(libName, sizeof(Elf32_Ehdr))).machine == rdi(hdr->e_machine)) {
++                    neededLibFound[j] = true;
++                    libFound = true;
++                } else
++                    debug("ignoring library '%s' because its machine type differs\n", libName.c_str());
++            } catch (SysError & e) {
++                if (e.errNo != ENOENT) throw;
++            }
++        }
++    return libFound;
++}
+ 
+ template<ElfFileParams>
+ void ElfFile<ElfFileParamNames>::modifyRPath(RPathOp op,
+-    const std::vector<std::string> & allowedRpathPrefixes, std::string newRPath)
++    const std::vector<std::string> & allowedRpathPrefixes,
++    std::string rootDir, int flags, std::string newRPath)
+ {
+     Elf_Shdr & shdrDynamic = findSection(".dynamic");
+ 
+@@ -1153,11 +1215,14 @@ void ElfFile<ElfFileParamNames>::modifyRPath(RPathOp op,
+         return;
+     }
+ 
++    if (op == rpMakeRelative && !rpath) {
++        debug("no RPATH to make relative\n");
++        return;
++    }
+ 
+     /* For each directory in the RPATH, check if it contains any
+        needed library. */
+     if (op == rpShrink) {
+-        std::vector<bool> neededLibFound(neededLibs.size(), false);
+ 
+         newRPath = "";
+ 
+@@ -1177,30 +1242,78 @@ void ElfFile<ElfFileParamNames>::modifyRPath(RPathOp op,
+                 continue;
+             }
+ 
+-            /* For each library that we haven't found yet, see if it
+-               exists in this directory. */
+-            bool libFound = false;
+-            for (unsigned int j = 0; j < neededLibs.size(); ++j)
+-                if (!neededLibFound[j]) {
+-                    std::string libName = dirName + "/" + neededLibs[j];
+-                    try {
+-                        if (getElfType(readFile(libName, sizeof(Elf32_Ehdr))).machine == rdi(hdr->e_machine)) {
+-                            neededLibFound[j] = true;
+-                            libFound = true;
+-                        } else
+-                            debug("ignoring library '%s' because its machine type differs\n", libName.c_str());
+-                    } catch (SysError & e) {
+-                        if (e.errNo != ENOENT) throw;
+-                    }
+-                }
+-
+-            if (!libFound)
++            if (!libFoundInRPath(dirName, neededLibs))
+                 debug("removing directory '%s' from RPATH\n", dirName.c_str());
+             else
+                 concatToRPath(newRPath, dirName);
+         }
+     }
+ 
++    /* Make the the RPATH relative to the specified path */
++    if (op == rpMakeRelative) {
++        std::string fileDir = fileName.substr(0, fileName.find_last_of("/"));
++        newRPath = "";
++
++        for (auto & dirName : splitColonDelimitedString(rpath)) {
++            std::string canonicalPath;
++
++            /* Figure out if we should keep or discard the path. There are several
++               cases to be handled:
++               "dirName" starts with "$ORIGIN":
++                   The original build-system already took care of setting a relative
++                   RPATH. Resolve it and test if it's valid (does exist).
++               "dirName" start with "rootDir":
++                   The original build-system added some absolute RPATH (absolute on
++                   the build machine). Test if it's valid (does exist).
++               "rootDir"/"dirName" exists:
++                    The original build-system already took care of setting an absolute
++                    RPATH (absolute in the final rootfs). Resolve it and test if it's
++                    valid (does exist).
++               "dirName" points somewhere else:
++                    (can be anywhere: build trees, staging tree, host location,
++                    non-existing location, etc.). Just discard such a path. */
++            if (!dirName.compare(0, 7, "$ORIGIN")) {
++                std::string path = fileDir + dirName.substr(7);
++                if (!absolutePathExists(path, canonicalPath)) {
++                    debug("removing directory '%s' from RPATH because '%s' doesn't exist\n",
++			  dirName.c_str(), path.c_str());
++                    continue;
++                }
++            } else if (!dirName.compare(0, rootDir.length(), rootDir)) {
++                if (!absolutePathExists(dirName, canonicalPath)) {
++                    debug("removing directory '%s' from RPATH because it doesn't exist\n", dirName.c_str());
++                    continue;
++                }
++            } else {
++                std::string path = rootDir + dirName;
++                if (!absolutePathExists(path, canonicalPath)) {
++                    debug("removing directory '%s' from RPATH because '%s' doesn't exist\n",
++			  dirName.c_str(), path.c_str());
++                    continue;
++                }
++            }
++
++            if (flags & MODIFY_FLAG_NO_STD_LIB_DIRS) {
++                if (!canonicalPath.compare(rootDir + "/lib") ||
++                    !canonicalPath.compare(rootDir + "/usr/lib")) {
++                    debug("removing directory '%s' from RPATH because it's a standard library directory\n",
++                         dirName.c_str());
++                    continue;
++                }
++            }
++
++            if (!libFoundInRPath(canonicalPath, neededLibs)) {
++                debug("removing directory '%s' from RPATH because it does not contain needed libs\n",
++		      dirName.c_str());
++                continue;
++            }
++
++            /* Finally make "canonicalPath" relative to "filedir" in "rootDir" */
++            concatToRPath(newRPath, makePathRelative(canonicalPath, fileDir, rootDir));
++            debug("keeping relative path of %s\n", canonicalPath.c_str());
++        }
++    }
++
+     if (op == rpRemove) {
+         if (!rpath) {
+             debug("no RPATH to delete\n");
+@@ -1528,7 +1641,9 @@ static std::vector<std::string> allowedRpathPrefixes;
+ static bool removeRPath = false;
+ static bool setRPath = false;
+ static bool printRPath = false;
++static bool makeRPathRelative = false;
+ static std::string newRPath;
++static std::string rootDir;
+ static std::set<std::string> neededLibsToRemove;
+ static std::map<std::string, std::string> neededLibsToReplace;
+ static std::set<std::string> neededLibsToAdd;
+@@ -1551,14 +1666,16 @@ static void patchElf2(ElfFile && elfFile)
+         elfFile.setInterpreter(newInterpreter);
+ 
+     if (printRPath)
+-        elfFile.modifyRPath(elfFile.rpPrint, {}, "");
++        elfFile.modifyRPath(elfFile.rpPrint, {}, {}, modifyFlags, "");
+ 
+     if (shrinkRPath)
+-        elfFile.modifyRPath(elfFile.rpShrink, allowedRpathPrefixes, "");
++        elfFile.modifyRPath(elfFile.rpShrink, allowedRpathPrefixes, "", modifyFlags, "");
+     else if (removeRPath)
+-        elfFile.modifyRPath(elfFile.rpRemove, {}, "");
++        elfFile.modifyRPath(elfFile.rpRemove, {}, "", modifyFlags, "");
+     else if (setRPath)
+-        elfFile.modifyRPath(elfFile.rpSet, {}, newRPath);
++        elfFile.modifyRPath(elfFile.rpSet, {}, "", modifyFlags, newRPath);
++    else if (makeRPathRelative)
++        elfFile.modifyRPath(elfFile.rpMakeRelative, {}, rootDir, modifyFlags, "");
+ 
+     if (printNeeded) elfFile.printNeededLibs();
+ 
+@@ -1604,6 +1721,8 @@ void showHelp(const std::string & progName)
+   [--remove-rpath]\n\
+   [--shrink-rpath]\n\
+   [--allowed-rpath-prefixes PREFIXES]\t\tWith '--shrink-rpath', reject rpath entries not starting with the allowed prefix\n\
++  [--make-rpath-relative ROOTDIR]\n\
++  [--no-standard-lib-dirs]\n\
+   [--print-rpath]\n\
+   [--force-rpath]\n\
+   [--add-needed LIBRARY]\n\
+@@ -1664,6 +1783,14 @@ int mainWrapped(int argc, char * * argv)
+             setRPath = true;
+             newRPath = argv[i];
+         }
++        else if (arg == "--make-rpath-relative") {
++            if (++i == argc) error("missing argument to --make-rpath-relative");
++            makeRPathRelative = true;
++            rootDir = argv[i];
++        }
++        else if (arg == "--no-standard-lib-dirs") {
++            modifyFlags |= MODIFY_FLAG_NO_STD_LIB_DIRS;
++        }
+         else if (arg == "--print-rpath") {
+             printRPath = true;
+         }
+-- 
+1.9.1
+
-- 
1.9.1

[Buildroot] [RFC PATCH v3 03/10] support/scripts: add fix-rpath script to sanitize the rpath

[Wolfgang Grandegger]

From: Samuel Martin <s.martin49@gmail.com>

This commit introduces the script "fix-rpath" able to scan a tree,
detect ELF files, check their RPATH and fix it in a proper way.
The RPATH fixup is done by the patchelf utility using the option
"--make-rpath-relative <root-directory>".

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 support/scripts/fix-rpath | 103 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 103 insertions(+)
 create mode 100755 support/scripts/fix-rpath

diff --git a/support/scripts/fix-rpath b/support/scripts/fix-rpath
new file mode 100755
index 0000000..5702b9a
--- /dev/null
+++ b/support/scripts/fix-rpath
@@ -0,0 +1,103 @@
+#!/usr/bin/env bash
+
+# Copyright (C) 2016 Samuel Martin <s.martin49@gmail.com>
+#
+# 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
+
+usage() {
+  cat <<EOF >&2
+Usage:	${0} TREE_KIND
+
+Description:
+
+    This script scans a tree and sanitize ELF files' RPATH found in there.
+
+    Sanitization behaves the same whatever the kind of the processed tree,
+    but the resulting RPATH differs. The rpath sanitization is done using
+    "patchelf --make-rpath-relazive".
+
+Arguments:
+
+    TREE_KIND	Kind of tree to be processed.
+		Allowed values: host, target
+
+Environment:
+
+    PATCHELF	patchelf program to use
+		(default: HOST_DIR/usr/bin/patchelf)
+EOF
+}
+
+: ${PATCHELF:=${HOST_DIR}/usr/bin/patchelf}
+
+main() {
+    local rootdir
+    local tree="${1}"
+    local find_args=( )
+    local sanitize_extra_args=( )
+
+    case "${tree}" in
+	host)
+	    rootdir="${HOST_DIR}"
+
+	    # do not process the sysroot (only contains target binaries)
+	    find_args+=( "-path" "${STAGING_DIR}" "-prune" "-o" )
+
+	    # do not process the external toolchain installation directory to
+	    # avoid breaking it.
+	    test "${TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR}" != "" && \
+		find_args+=( "-path" "${TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR}" "-prune" "-o" )
+
+	    # ELF files should not be in these sub-directories
+	    find_args+=( "-path" "${STAGING_DIR}/usr/share/terminfo" "-prune" "-o" )
+
+	    # do not process the patchelf binary but a copy to work-around "file in use"
+	    find_args+=( "-path" "${PATCHELF}" "-prune" "-o" )
+	    cp "${PATCHELF}" "${PATCHELF}.__to_be_patched"
+	    ;;
+
+	target)
+	    rootdir="${TARGET_DIR}"
+	    sanitize_extra_args+=( "--no-standard-lib-dirs" )
+	    ;;
+
+	*)
+	    usage
+	    exit 1
+	    ;;
+    esac
+
+    find_args+=( "-type" "f" "-print" )
+
+    while read file ; do
+	# check if it's an ELF file
+	if ${PATCHELF} --print-rpath "${file}" > /dev/null 2>&1; then
+	    # make files writable if necessary
+	    changed=$(chmod -c u+w "${file}")
+	    # call patchelf to sanitize the rpath
+	    ${PATCHELF} --make-rpath-relative "${rootdir}" ${sanitize_extra_args[@]} "${file}"
+	    # restore the original permission
+	    test "${changed}" != "" && chmod u-w "${file}"
+	fi
+    done < <(find "${rootdir}" ${find_args[@]})
+
+    # Restore patched patchelf utility
+    test "${tree}" = "host" && mv "${PATCHELF}.__to_be_patched" "${PATCHELF}"
+
+    # ignore errors
+    return 0
+}
+
+main ${@}
-- 
1.9.1

[Buildroot] [RFC PATCH v3 04/10] core: sanitize RPATH in host tree at the very end of the build

[Wolfgang Grandegger]

We need the patchelf host utility to check and fix the rpath.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Makefile b/Makefile
index fb2c235..41d100e 100644
--- a/Makefile
+++ b/Makefile
@@ -543,7 +543,12 @@ $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
 
 prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 
+# We need patchelf for RPATH sanitation
+PACKAGES += host-patchelf
+
 world: target-post-image
+	@$(call MESSAGE,"Rendering the SDK relocatable")
+	$(TOPDIR)/support/scripts/fix-rpath host
 
 .PHONY: all world toolchain dirs clean distclean source outputmakefile \
 	legal-info legal-info-prepare legal-info-clean printvars help \
-- 
1.9.1

[Buildroot] [RFC PATCH v3 05/10] core: sanitize RPATH in target tree at the end of the target finalization

[Wolfgang Grandegger]

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile b/Makefile
index 41d100e..aea85c8 100644
--- a/Makefile
+++ b/Makefile
@@ -716,6 +716,9 @@ endif
 		$(call MESSAGE,"Executing post-build script $(s)"); \
 		$(EXTRA_ENV) $(s) $(TARGET_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
 
+	@$(call MESSAGE,"Sanitizing RPATH in target tree")
+	$(TOPDIR)/support/scripts/fix-rpath target
+
 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] [RFC PATCH v3 06/10] support/scripts: add reloacte-sdk.sh script for SDK relocation

[Wolfgang Grandegger]

It will install the script "relocate-sdk.sh" in the HOST_DIR
allowing to adjust the path to the SDK directory in all text
files after it has been moved to a new location.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 support/misc/relocate-sdk.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100755 support/misc/relocate-sdk.sh

diff --git a/support/misc/relocate-sdk.sh b/support/misc/relocate-sdk.sh
new file mode 100755
index 0000000..1b0be33
--- /dev/null
+++ b/support/misc/relocate-sdk.sh
@@ -0,0 +1,47 @@
+#!/bin/bash
+#
+if [ "$#" -ne 0 ]; then
+    echo "Run this script to relocate the buildroot SDK at that location"
+    exit 1
+fi
+
+LOCFILE="./usr/share/buildroot/sdk-location"
+FILEPATH="$(readlink -f "$0")"
+NEWPATH="$(dirname "${FILEPATH}")"
+
+cd "${NEWPATH}"
+if [ ! -r "${LOCFILE}" ]; then
+    echo "Previous location of the buildroot SDK not found!"
+    exit 1
+fi
+OLDPATH="$(cat "${LOCFILE}")"
+
+if [ "${NEWPATH}" = "${OLDPATH}" ]; then
+    echo "This buildroot SDK has already been relocated!"
+    exit 0
+fi
+
+# Check if the path substitution does work properly, e.g.
+# a tree "/a/b/c" copied into "/a/b/c/" would not be allowed.
+newpath="$(sed -e "s\\${OLDPATH}\\${NEWPATH}\\g" "${LOCFILE}")"
+if [ "${NEWPATH}" != "${newpath}" ]; then
+    echo "Something went wrong with substituting the path!"
+    echo "Please choose another location for your SDK!"
+    exit 1
+fi
+
+echo "Relocating the buildroot SDK from ${OLDPATH} to ${NEWPATH} ..."
+
+# Make sure file uses the right language
+export LC_ALL=C
+# Replace the old path with the new one in all text files
+while read -r FILE ; do
+    if file -b --mime-type "${FILE}" | grep -q '^text/' && [ "${FILE}" != "${LOCFILE}" ]
+    then
+	sed -i "s\\${OLDPATH}\\${NEWPATH}\\g" "${FILE}"
+    fi;
+done < <(grep -lr "${OLDPATH}" .)
+
+# At the very end, we update the location file to not break the
+# SDK if this script gets interruted.
+sed -i "s\\${OLDPATH}\\${NEWPATH}\\g" ${LOCFILE}
-- 
1.9.1

[Buildroot] [RFC PATCH v3 07/10] core: install relocation script and location at the end of the build

[Wolfgang Grandegger]

The script "relocate-sdk.sh" is installed into the the top directory
of the SDK (HOST_DIR) and the SDK location path is stored in the
file "HOST_DIR/usr/share/buildroot/sdk-location"-

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index aea85c8..5e61b39 100644
--- a/Makefile
+++ b/Makefile
@@ -549,6 +549,8 @@ PACKAGES += host-patchelf
 world: target-post-image
 	@$(call MESSAGE,"Rendering the SDK relocatable")
 	$(TOPDIR)/support/scripts/fix-rpath host
+	install $(TOPDIR)/support/misc/relocate-sdk.sh $(HOST_DIR) && \
+	echo $(HOST_DIR) > $(HOST_DIR)/usr/share/buildroot/sdk-location
 
 .PHONY: all world toolchain dirs clean distclean source outputmakefile \
 	legal-info legal-info-prepare legal-info-clean printvars help \
-- 
1.9.1

[Buildroot] [RFC PATCH v3 08/10] external-toolchain: check if a buildroot SDK has already been relocated

[Wolfgang Grandegger]

The location of the buildroot SDK is stored in the file "sdk-location"
in "usr/share/buildroot". If it's content does not match the current
SDK location, ask the user to run the script "relocate-sdk.sh" in the
top directory once.

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 toolchain/helpers.mk                                   | 15 +++++++++++++++
 toolchain/toolchain-external/pkg-toolchain-external.mk |  1 +
 2 files changed, 16 insertions(+)

diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index 2f73ebb..5f6e3e0 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -394,3 +394,18 @@ check_toolchain_ssp = \
 gen_gdbinit_file = \
 	mkdir -p $(STAGING_DIR)/usr/share/buildroot/ ; \
 	echo "set sysroot $(STAGING_DIR)" > $(STAGING_DIR)/usr/share/buildroot/gdbinit
+
+#
+# Check if it's a buildroot toolchain and if it's already relocatable by
+# reading and testing the toolchain location file
+#
+# $1: toolchain installation directory
+#
+check_buildroot_sdk_relocated = \
+	if [ -r $(1)/share/buildroot/sdk-location ]; then \
+		sdkroot=`dirname "$(1)"`; \
+		if [ "`cat $(1)/share/buildroot/sdk-location`" != "$${sdkroot}" ]; then \
+			echo "Please relocate the buildroot SDK by executing \"$${sdkroot}/relocate-sdk.sh\" once!" ; \
+			exit 1 ; \
+		fi \
+	fi
diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index 11a1bf5..b9ffa80 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -543,6 +543,7 @@ endif
 # matches the configuration provided in Buildroot: ABI, C++ support,
 # kernel headers version, type of C library and all C library features.
 define $(2)_CONFIGURE_CMDS
+	$$(Q)$$(call check_buildroot_sdk_relocated,$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR))
 	$$(Q)$$(call check_cross_compiler_exists,$$(TOOLCHAIN_EXTERNAL_CC))
 	$$(Q)$$(call check_unusable_toolchain,$$(TOOLCHAIN_EXTERNAL_CC))
 	$$(Q)SYSROOT_DIR="$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))" ; \
-- 
1.9.1

[Buildroot] [RFC PATCH v3 09/10] support/scripts: check-host-rpath now handles $ORIGIN as well

[Wolfgang Grandegger]

"$ORIGIN/../../usr/lib" is also a valid RPATH for binaries in
"$hostdir/usr/bin". After RPATH sanitation, all RPATH
directories start with "$ORIGIN".

Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 support/scripts/check-host-rpath | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/scripts/check-host-rpath b/support/scripts/check-host-rpath
index 6ce547c..020c123 100755
--- a/support/scripts/check-host-rpath
+++ b/support/scripts/check-host-rpath
@@ -58,7 +58,7 @@ check_elf_has_rpath() {
         for dir in ${rpath//:/ }; do
             # Remove duplicate and trailing '/' for proper match
             dir="$( sed -r -e 's:/+:/:g; s:/$::;' <<<"${dir}" )"
-            [ "${dir}" = "${hostdir}/usr/lib" ] && return 0
+            [ "${dir}" = "${hostdir}/usr/lib" -o "${dir}" = "\$ORIGIN/../../usr/lib" ] && return 0
         done
     done < <( readelf -d "${file}"                                              \
               |sed -r -e '/.* \(R(UN)?PATH\) +Library r(un)?path: \[(.+)\]$/!d' \
-- 
1.9.1

[Buildroot] [RFC PATCH v3 10/10] package/qt5base: provide "qt.conf" to make "qmake" relocatable

[Wolfgang Grandegger]

The file "qt.conf" can be used to override the hard-coded paths that are
compiled into the Qt library. We need it to make "qmake" relocatable.

CC: Julien Corjon <corjon.j@ecagroup.com>
CC: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
 package/qt5/qt5base/qt.conf.in | 6 ++++++
 package/qt5/qt5base/qt5base.mk | 8 ++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 package/qt5/qt5base/qt.conf.in

diff --git a/package/qt5/qt5base/qt.conf.in b/package/qt5/qt5base/qt.conf.in
new file mode 100644
index 0000000..48e4b92
--- /dev/null
+++ b/package/qt5/qt5base/qt.conf.in
@@ -0,0 +1,6 @@
+[Paths]
+Prefix=@@HOST_DIR@@/usr
+Sysroot=@@STAGING_DIR@@
+Headers=/usr/include/qt5
+Plugins=/usr/lib/qt/plugins
+Examples=/usr/lib/qt/examples
diff --git a/package/qt5/qt5base/qt5base.mk b/package/qt5/qt5base/qt5base.mk
index 1020348..e42e395 100644
--- a/package/qt5/qt5base/qt5base.mk
+++ b/package/qt5/qt5base/qt5base.mk
@@ -253,9 +253,17 @@ define QT5BASE_BUILD_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)
 endef
 
+# The file "qt.conf" can be used to override the hard-coded paths that are
+# compiled into the Qt library. We need it to make "qmake" relocatable.
+define QT5BASE_INSTALL_QT_CONF
+	sed -e "s\\@@HOST_DIR@@\\$(HOST_DIR)\\" -e "s\\@@STAGING_DIR@@\\$(STAGING_DIR)\\" \
+	$(QT5BASE_PKGDIR)/qt.conf.in > $(HOST_DIR)/usr/bin/qt.conf
+endef
+
 define QT5BASE_INSTALL_STAGING_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) install
 	$(QT5_LA_PRL_FILES_FIXUP)
+	$(QT5BASE_INSTALL_QT_CONF)
 endef
 
 define QT5BASE_INSTALL_TARGET_LIBS
-- 
1.9.1

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 23-03-17 08:54, Wolfgang Grandegger wrote:
> Hello,
> 
> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
> relocatable. It sanitizes the RPATH of all ELF files in the "target"
> and "host" tree using "patchelf --make-rpath-relative". I have started
> the mainlining process implementing "--make-rpath-relative" using
> GitHub pull request [1]... till now, no answer!
> 
> Furthermore this patch creates the script "relocate-sdk.sh" in the top
> directory of the "host" tree allowing to relocate the SDK after it has
> been moved to a new location. It replaces the old path with the new
> one in all text files identified by "file --mime-type". The location
> is stored in "usr/share/buildroot/sdk-location".
> 
> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
> 
> Other Questions:
> 
> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>   files in the target tree. "/lib" and "/usr/lib" have been removed
>   already. 

 Good point, I don't think we want that... Neither for the ones in staging, I
suppose. The RPATHs there should all be absolute paths which should be
interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).

 I'm not entirely sure about staging, whether ld will use RPATH as an
alternative to -L and in that case whether it is done relative to sysroot or not.

> 
> Things not yet addressed:
> 
> - "make toolchain" creates a toolchain tree which still has references
>   to the build system (in ELF and text files).  

 A solution to this (and other problems) is to use the same approach as
check-bin-arch: do it as an instrumentation hook for each package, and only look
at the files added by that package. That way, the overhead is spread out over
the entire build process, and doing rebuilds doesn't run patchelf on all files
anymore in the finalize step.



 Regards,
 Arnout

[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello Arnout,

Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>
>
> On 23-03-17 08:54, Wolfgang Grandegger wrote:
>> Hello,
>>
>> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
>> relocatable. It sanitizes the RPATH of all ELF files in the "target"
>> and "host" tree using "patchelf --make-rpath-relative". I have started
>> the mainlining process implementing "--make-rpath-relative" using
>> GitHub pull request [1]... till now, no answer!
>>
>> Furthermore this patch creates the script "relocate-sdk.sh" in the top
>> directory of the "host" tree allowing to relocate the SDK after it has
>> been moved to a new location. It replaces the old path with the new
>> one in all text files identified by "file --mime-type". The location
>> is stored in "usr/share/buildroot/sdk-location".
>>
>> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
>> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
>>
>> Other Questions:
>>
>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>   files in the target tree. "/lib" and "/usr/lib" have been removed
>>   already.
>
>  Good point, I don't think we want that... Neither for the ones in staging, I
> suppose. The RPATHs there should all be absolute paths which should be
> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).

Could be done, no problem. Just requires some further modifications to 
patchelf. BTW, so far I have not received any response to my related 
Github pull request... like many others:

   https://github.com/NixOS/patchelf/pulls

The project seems not really to be maintained... or I use the wrong 
channel. In principle we could maintain your own version.

>  I'm not entirely sure about staging, whether ld will use RPATH as an
> alternative to -L and in that case whether it is done relative to sysroot or not.

So far, the patch series works for me very well. Just my usecase, of course.

>> Things not yet addressed:
>>
>> - "make toolchain" creates a toolchain tree which still has references
>>   to the build system (in ELF and text files).
>
>  A solution to this (and other problems) is to use the same approach as
> check-bin-arch: do it as an instrumentation hook for each package, and only look
> at the files added by that package. That way, the overhead is spread out over
> the entire build process, and doing rebuilds doesn't run patchelf on all files
> anymore in the finalize step.

This is just to solve the issue mentioned above or a general approach 
(instead of doning rtpath sanitation at the end)?

How should I go ahead to get this patch series accepted sooner than 
later? We could make the option configurable, for example, to reduce the 
risk of breaking something.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello,

this topic is still pending... some more input below...

Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
> Hello Arnout,
> 
> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>
>>
>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
>>> Hello,
>>>
>>> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
>>> relocatable. It sanitizes the RPATH of all ELF files in the "target"
>>> and "host" tree using "patchelf --make-rpath-relative". I have started
>>> the mainlining process implementing "--make-rpath-relative" using
>>> GitHub pull request [1]... till now, no answer!
>>>
>>> Furthermore this patch creates the script "relocate-sdk.sh" in the top
>>> directory of the "host" tree allowing to relocate the SDK after it has
>>> been moved to a new location. It replaces the old path with the new
>>> one in all text files identified by "file --mime-type". The location
>>> is stored in "usr/share/buildroot/sdk-location".
>>>
>>> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
>>> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
>>>
>>> Other Questions:
>>>
>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>   files in the target tree. "/lib" and "/usr/lib" have been removed
>>>   already.
>>
>>  Good point, I don't think we want that... Neither for the ones in 
>> staging, I
>> suppose. The RPATHs there should all be absolute paths which should be
>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
> 
> Could be done, no problem. Just requires some further modifications to 

I just learned that using relative path for the target breaks "sudo", at 
least. I'm going to rework patchelf...

> patchelf. BTW, so far I have not received any response to my related 
> Github pull request... like many others:
> 
>    https://github.com/NixOS/patchelf/pulls
> 
> The project seems not really to be maintained... or I use the wrong 
> channel. In principle we could maintain your own version.

I have little hope that we can get this patch accepted. Nobody seems to 
care :(. What about maintaining our own version?

>>  I'm not entirely sure about staging, whether ld will use RPATH as an
>> alternative to -L and in that case whether it is done relative to 
>> sysroot or not.
> 
> So far, the patch series works for me very well. Just my usecase, of 
> course.
> 
>>> Things not yet addressed:
>>>
>>> - "make toolchain" creates a toolchain tree which still has references
>>>   to the build system (in ELF and text files).
>>
>>  A solution to this (and other problems) is to use the same approach as
>> check-bin-arch: do it as an instrumentation hook for each package, and 
>> only look
>> at the files added by that package. That way, the overhead is spread 
>> out over
>> the entire build process, and doing rebuilds doesn't run patchelf on 
>> all files
>> anymore in the finalize step.
> 
> This is just to solve the issue mentioned above or a general approach 
> (instead of doning rtpath sanitation at the end)?

Any opinions here?

> How should I go ahead to get this patch series accepted sooner than 
> later? We could make the option configurable, for example, to reduce the 
> risk of breaking something.

Is a relocatable SDK still on the wish list? How should/could I proceed 
to get the feature accepted sooner than later?

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

 Hi Wolfgang,

On 21-06-17 09:59, Wolfgang Grandegger wrote:
> Hello,
> 
> this topic is still pending... some more input below...
> 
> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>> Hello Arnout,
>>
>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>
>>>
>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
>>>> Hello,
>>>>
>>>> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
>>>> relocatable. It sanitizes the RPATH of all ELF files in the "target"
>>>> and "host" tree using "patchelf --make-rpath-relative". I have started
>>>> the mainlining process implementing "--make-rpath-relative" using
>>>> GitHub pull request [1]... till now, no answer!
>>>>
>>>> Furthermore this patch creates the script "relocate-sdk.sh" in the top
>>>> directory of the "host" tree allowing to relocate the SDK after it has
>>>> been moved to a new location. It replaces the old path with the new
>>>> one in all text files identified by "file --mime-type". The location
>>>> is stored in "usr/share/buildroot/sdk-location".
>>>>
>>>> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
>>>> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
>>>>
>>>> Other Questions:
>>>>
>>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>>   files in the target tree. "/lib" and "/usr/lib" have been removed
>>>>   already.
>>>
>>>  Good point, I don't think we want that... Neither for the ones in staging, I
>>> suppose. The RPATHs there should all be absolute paths which should be
>>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
>>
>> Could be done, no problem. Just requires some further modifications to 
> 
> I just learned that using relative path for the target breaks "sudo", at least.

 So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
libsudo_util.so.0 at runtime? Or how does it break?

> I'm going to rework patchelf...
> 
>> patchelf. BTW, so far I have not received any response to my related Github
>> pull request... like many others:
>>
>>    https://github.com/NixOS/patchelf/pulls
>>
>> The project seems not really to be maintained... or I use the wrong channel.
>> In principle we could maintain your own version.
> 
> I have little hope that we can get this patch accepted. Nobody seems to care :(.
> What about maintaining our own version?

 Since we need just a single patch for the time being, I think maintaining it as
a patch is sufficient.


>>>  I'm not entirely sure about staging, whether ld will use RPATH as an
>>> alternative to -L and in that case whether it is done relative to sysroot or
>>> not.
>>
>> So far, the patch series works for me very well. Just my usecase, of course.

 IIRC I checked a while ago and it looked like ld would use RPATH as a link path
(i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
Which means that we shouldn't make the RPATHs in staging relative to
STAGING_DIR, otherwise it may pick up the library from the host. This really
shouldn't happen because the link normally should get the appropriate -L flag to
find the target lib and the -L has precedence over RPATH, but better be safe.

 Again, I don't remember exactly so the previous paragraph could be entirely
wrong :-)


>>>> Things not yet addressed:
>>>>
>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>   to the build system (in ELF and text files).
>>>
>>>  A solution to this (and other problems) is to use the same approach as
>>> check-bin-arch: do it as an instrumentation hook for each package, and only look
>>> at the files added by that package. That way, the overhead is spread out over
>>> the entire build process, and doing rebuilds doesn't run patchelf on all files
>>> anymore in the finalize step.
>>
>> This is just to solve the issue mentioned above or a general approach (instead
>> of doning rtpath sanitation at the end)?
> 
> Any opinions here?

 Preferably as an instrumentation hook, because:
- it speeds things up dramatically if you do 'make foo-rebuild';
- things are still correct if you interrupt the build in the middle;
- it makes no difference if you do a rebuild (if patchelf is done at the end,
and then you rebuild a package, the RPATH in the libs you link with is different
than the first time you built it).


>> How should I go ahead to get this patch series accepted sooner than later? We
>> could make the option configurable, for example, to reduce the risk of
>> breaking something.
> 
> Is a relocatable SDK still on the wish list? How should/could I proceed to get
> the feature accepted sooner than later?

 You should pray that someone takes the time to continue the review :-)

 Occasionally drawing attention to the series like you do know definitely helps.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 21-06-17 23:03, Arnout Vandecappelle wrote:
>  Preferably as an instrumentation hook, because:
> - it speeds things up dramatically if you do 'make foo-rebuild';
> - things are still correct if you interrupt the build in the middle;
> - it makes no difference if you do a rebuild (if patchelf is done at the end,
> and then you rebuild a package, the RPATH in the libs you link with is different
> than the first time you built it).

 Note, however, that doing it as an instrumentation hook could be a pretty
dramatic rewrite of your series, so if you don't feel up to it, I'm ok with
committing the current approach to begin with.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello,

Am 21.06.2017 um 23:06 schrieb Arnout Vandecappelle:
> 
> 
> On 21-06-17 23:03, Arnout Vandecappelle wrote:
>>   Preferably as an instrumentation hook, because:
>> - it speeds things up dramatically if you do 'make foo-rebuild';
>> - things are still correct if you interrupt the build in the middle;
>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>> and then you rebuild a package, the RPATH in the libs you link with is different
>> than the first time you built it).
> 
>   Note, however, that doing it as an instrumentation hook could be a pretty
> dramatic rewrite of your series, so if you don't feel up to it, I'm ok with
> committing the current approach to begin with.

I just sent out v4 of my patch series doing the sanitation at the end of 
the build. Yes, using GLOBAL_INSTRUMENTATION_HOOKS would requires 
further modification to the framework. But also "check-bin-arch" and 
"check-host-rpath" does a lot of useless scanning for ELF files.
Therefore it would make sense to use this mechanism to create a list of 
ELF files similar to the hook "step_pkg_size" (creating 
packages-file-list.txt), either per installation step or even better per 
package:

   build/target-packages-elf-files.txt
   build/staging-packages-elf-files.txt
   build/host-packages-elf-files.txt

or (per package)

   build/elf-file-list/<host|staging|target>-<package>-elf-files.txt

If we do not need the per package list lateron, we could create it
temporarily, call "fix-rpath" to do the sanitation and delete it 
afterwards. Or, even simpler, fix-rpath could work on 
".br_filelist_before" and ".br_filelist_after" directly... that seems 
not too difficult to implement. What do you think?

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 27-06-17 12:54, Wolfgang Grandegger wrote:
> Hello,
> 
> Am 21.06.2017 um 23:06 schrieb Arnout Vandecappelle:
>>
>>
>> On 21-06-17 23:03, Arnout Vandecappelle wrote:
>>>   Preferably as an instrumentation hook, because:
>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>> - things are still correct if you interrupt the build in the middle;
>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>> and then you rebuild a package, the RPATH in the libs you link with is different
>>> than the first time you built it).
>>
>>   Note, however, that doing it as an instrumentation hook could be a pretty
>> dramatic rewrite of your series, so if you don't feel up to it, I'm ok with
>> committing the current approach to begin with.
> 
> I just sent out v4 of my patch series doing the sanitation at the end of the
> build. Yes, using GLOBAL_INSTRUMENTATION_HOOKS would requires further
> modification to the framework. But also "check-bin-arch" and "check-host-rpath"
> does a lot of useless scanning for ELF files.
> Therefore it would make sense to use this mechanism to create a list of ELF
> files similar to the hook "step_pkg_size" (creating packages-file-list.txt),
> either per installation step or even better per package:
> 
>   build/target-packages-elf-files.txt
>   build/staging-packages-elf-files.txt
>   build/host-packages-elf-files.txt
> 
> or (per package)
> 
>   build/elf-file-list/<host|staging|target>-<package>-elf-files.txt

 I definitely like the per-package file list, because it smoothly scales to
per-package-staging. Ideally then the packages-file-list.txt should also be
split into a separate list per package. From there it's a small step to have an
elf-file list as well.

 Since it's anyway per-package, I'd put it directly in the package build
directory, e.g. $(@D)/.<host|staging|target>-files.txt and
$(@D)/.<host|staging|target>-elf-files.txt.

 But as I understand it, your proposal is to commit your series as is, with the
scanning done only in the finalize step, and refactor it with elf files lists later?


> If we do not need the per package list lateron, we could create it
> temporarily, call "fix-rpath" to do the sanitation and delete it afterwards. Or,
> even simpler, fix-rpath could work on ".br_filelist_before" and
> ".br_filelist_after" directly... that seems not too difficult to implement. What
> do you think?

 The latter was actually what I had in mind: refactor the step_pkg_size_end to
save the output of comm in a temporary file, and use that file to call the
fix-rpath script. That temporary file is basically $(@D)/.target-files.txt.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 00:41 schrieb Arnout Vandecappelle:
> 
> 
> On 27-06-17 12:54, Wolfgang Grandegger wrote:
>> Hello,
>>
>> Am 21.06.2017 um 23:06 schrieb Arnout Vandecappelle:
>>>
>>>
>>> On 21-06-17 23:03, Arnout Vandecappelle wrote:
>>>>    Preferably as an instrumentation hook, because:
>>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>>> - things are still correct if you interrupt the build in the middle;
>>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>>> and then you rebuild a package, the RPATH in the libs you link with is different
>>>> than the first time you built it).
>>>
>>>    Note, however, that doing it as an instrumentation hook could be a pretty
>>> dramatic rewrite of your series, so if you don't feel up to it, I'm ok with
>>> committing the current approach to begin with.
>>
>> I just sent out v4 of my patch series doing the sanitation at the end of the
>> build. Yes, using GLOBAL_INSTRUMENTATION_HOOKS would requires further
>> modification to the framework. But also "check-bin-arch" and "check-host-rpath"
>> does a lot of useless scanning for ELF files.
>> Therefore it would make sense to use this mechanism to create a list of ELF
>> files similar to the hook "step_pkg_size" (creating packages-file-list.txt),
>> either per installation step or even better per package:
>>
>>    build/target-packages-elf-files.txt
>>    build/staging-packages-elf-files.txt
>>    build/host-packages-elf-files.txt
>>
>> or (per package)
>>
>>    build/elf-file-list/<host|staging|target>-<package>-elf-files.txt
> 
>   I definitely like the per-package file list, because it smoothly scales to
> per-package-staging. Ideally then the packages-file-list.txt should also be
> split into a separate list per package. From there it's a small step to have an
> elf-file list as well.
> 
>   Since it's anyway per-package, I'd put it directly in the package build
> directory, e.g. $(@D)/.<host|staging|target>-files.txt and
> $(@D)/.<host|staging|target>-elf-files.txt.

OK, into $($(PKG)_DIR).

>   But as I understand it, your proposal is to commit your series as is, with the
> scanning done only in the finalize step, and refactor it with elf files lists later?

That would be a good starting point. The per package sanitation requires 
quiet some changes to the build infrastructure.

>> If we do not need the per package list lateron, we could create it
>> temporarily, call "fix-rpath" to do the sanitation and delete it afterwards. Or,
>> even simpler, fix-rpath could work on ".br_filelist_before" and
>> ".br_filelist_after" directly... that seems not too difficult to implement. What
>> do you think?
> 
>   The latter was actually what I had in mind: refactor the step_pkg_size_end to
> save the output of comm in a temporary file, and use that file to call the
> fix-rpath script. That temporary file is basically $(@D)/.target-files.txt.

I already started to implement that approach... more soon.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 28-06-17 08:51, Wolfgang Grandegger wrote:
> Am 28.06.2017 um 00:41 schrieb Arnout Vandecappelle:
[snip]
>>   But as I understand it, your proposal is to commit your series as is, with the
>> scanning done only in the finalize step, and refactor it with elf files lists
>> later?
> 
> That would be a good starting point. The per package sanitation requires quiet
> some changes to the build infrastructure.
> 
>>> If we do not need the per package list lateron, we could create it
>>> temporarily, call "fix-rpath" to do the sanitation and delete it afterwards. Or,
>>> even simpler, fix-rpath could work on ".br_filelist_before" and
>>> ".br_filelist_after" directly... that seems not too difficult to implement. What
>>> do you think?
>>
>>   The latter was actually what I had in mind: refactor the step_pkg_size_end to
>> save the output of comm in a temporary file, and use that file to call the
>> fix-rpath script. That temporary file is basically $(@D)/.target-files.txt.
> 
> I already started to implement that approach... more soon.

 If you could post an RFC series (even if unfinished) by Saturday evening, we
can still work on it during the Summer Camp.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 12:44 schrieb Arnout Vandecappelle:
> 
> 
> On 28-06-17 08:51, Wolfgang Grandegger wrote:
>> Am 28.06.2017 um 00:41 schrieb Arnout Vandecappelle:
> [snip]
>>>    But as I understand it, your proposal is to commit your series as is, with the
>>> scanning done only in the finalize step, and refactor it with elf files lists
>>> later?
>>
>> That would be a good starting point. The per package sanitation requires quiet
>> some changes to the build infrastructure.
>>
>>>> If we do not need the per package list lateron, we could create it
>>>> temporarily, call "fix-rpath" to do the sanitation and delete it afterwards. Or,
>>>> even simpler, fix-rpath could work on ".br_filelist_before" and
>>>> ".br_filelist_after" directly... that seems not too difficult to implement. What
>>>> do you think?
>>>
>>>    The latter was actually what I had in mind: refactor the step_pkg_size_end to
>>> save the output of comm in a temporary file, and use that file to call the
>>> fix-rpath script. That temporary file is basically $(@D)/.target-files.txt.
>>
>> I already started to implement that approach... more soon.
> 
>   If you could post an RFC series (even if unfinished) by Saturday evening, we
> can still work on it during the Summer Camp.

Yeah, that's feasible. A first hack is not that difficult. Makeing the 
scripts more effcient/elegant could be done later.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello Arnout,

Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>   Hi Wolfgang,
> 
> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>> Hello,
>>
>> this topic is still pending... some more input below...
>>
>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>> Hello Arnout,
>>>
>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>
>>>>
>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
>>>>> Hello,
>>>>>
>>>>> this is v3 of my RFC patch series to make the buildroot SDK (HOST_DIR)
>>>>> relocatable. It sanitizes the RPATH of all ELF files in the "target"
>>>>> and "host" tree using "patchelf --make-rpath-relative". I have started
>>>>> the mainlining process implementing "--make-rpath-relative" using
>>>>> GitHub pull request [1]... till now, no answer!
>>>>>
>>>>> Furthermore this patch creates the script "relocate-sdk.sh" in the top
>>>>> directory of the "host" tree allowing to relocate the SDK after it has
>>>>> been moved to a new location. It replaces the old path with the new
>>>>> one in all text files identified by "file --mime-type". The location
>>>>> is stored in "usr/share/buildroot/sdk-location".
>>>>>
>>>>> Unfortunately, "qmake" uses hard-coded pathes compiled into the QT5
>>>>> libraries. To overcome this problem, "qt5pase" now creates "qt.conf".
>>>>>
>>>>> Other Questions:
>>>>>
>>>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>>>    files in the target tree. "/lib" and "/usr/lib" have been removed
>>>>>    already.
>>>>
>>>>   Good point, I don't think we want that... Neither for the ones in staging, I
>>>> suppose. The RPATHs there should all be absolute paths which should be
>>>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
>>>
>>> Could be done, no problem. Just requires some further modifications to
>>
>> I just learned that using relative path for the target breaks "sudo", at least.
> 
>   So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
> libsudo_util.so.0 at runtime? Or how does it break?

Yep, that's the problem. I think it's because of "For security, the
dynamic linker does not allow use of $ORIGIN substitution sequences for
set-user and set-group ID programs..." from

  http://seclists.org/fulldisclosure/2010/Oct/257


>> I'm going to rework patchelf...

I now implemented the patchelf flags "--relative-to-file" for using $ORIGIN.

>>
>>> patchelf. BTW, so far I have not received any response to my related Github
>>> pull request... like many others:
>>>
>>>     https://github.com/NixOS/patchelf/pulls
>>>
>>> The project seems not really to be maintained... or I use the wrong channel.
>>> In principle we could maintain your own version.
>>
>> I have little hope that we can get this patch accepted. Nobody seems to care :(.
>> What about maintaining our own version?
> 
>   Since we need just a single patch for the time being, I think maintaining it as
> a patch is sufficient.
> 
> 
>>>>   I'm not entirely sure about staging, whether ld will use RPATH as an
>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>> not.
>>>
>>> So far, the patch series works for me very well. Just my usecase, of course.
> 
>   IIRC I checked a while ago and it looked like ld would use RPATH as a link path
> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
> Which means that we shouldn't make the RPATHs in staging relative to
> STAGING_DIR, otherwise it may pick up the library from the host. This really
> shouldn't happen because the link normally should get the appropriate -L flag to
> find the target lib and the -L has precedence over RPATH, but better be safe.

The man page of "ld" says:

"The linker uses the following search paths to locate required shared libraries:
 ...
 6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are
     searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries
     exist."

Then we should use $ORIGIN relative to the ELF file for the staging tree
(like for the host tree) to make it relocatable.

>   Again, I don't remember exactly so the previous paragraph could be entirely
> wrong :-)
> 
> 
>>>>> Things not yet addressed:
>>>>>
>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>    to the build system (in ELF and text files).
>>>>
>>>>   A solution to this (and other problems) is to use the same approach as
>>>> check-bin-arch: do it as an instrumentation hook for each package, and only look
>>>> at the files added by that package. That way, the overhead is spread out over
>>>> the entire build process, and doing rebuilds doesn't run patchelf on all files
>>>> anymore in the finalize step.
>>>
>>> This is just to solve the issue mentioned above or a general approach (instead
>>> of doning rtpath sanitation at the end)?
>>
>> Any opinions here?
> 
>   Preferably as an instrumentation hook, because:
> - it speeds things up dramatically if you do 'make foo-rebuild';
> - things are still correct if you interrupt the build in the middle;
> - it makes no difference if you do a rebuild (if patchelf is done at the end,
> and then you rebuild a package, the RPATH in the libs you link with is different
> than the first time you built it).

OK, as I see it, check-bin-arch is only for the files in the target tree. Having a
closer look now.

>>> How should I go ahead to get this patch series accepted sooner than later? We
>>> could make the option configurable, for example, to reduce the risk of
>>> breaking something.
>>
>> Is a relocatable SDK still on the wish list? How should/could I proceed to get
>> the feature accepted sooner than later?
> 
>   You should pray that someone takes the time to continue the review :-)
> 
>   Occasionally drawing attention to the series like you do know definitely helps.

OK, more soon...

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 22-06-17 08:37, Wolfgang Grandegger wrote:
> Hello Arnout,
> 
> Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>>   Hi Wolfgang,
>>
>> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>>> Hello,
>>>
>>> this topic is still pending... some more input below...
>>>
>>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>>> Hello Arnout,
>>>>
>>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>>
>>>>>
>>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
[snip]
>>>>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>>>>    files in the target tree. "/lib" and "/usr/lib" have been removed
>>>>>>    already.
>>>>>
>>>>>   Good point, I don't think we want that... Neither for the ones in staging, I
>>>>> suppose. The RPATHs there should all be absolute paths which should be
>>>>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
>>>>
>>>> Could be done, no problem. Just requires some further modifications to
>>>
>>> I just learned that using relative path for the target breaks "sudo", at least.
>>
>>   So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
>> libsudo_util.so.0 at runtime? Or how does it break?
> 
> Yep, that's the problem. I think it's because of "For security, the
> dynamic linker does not allow use of $ORIGIN substitution sequences for
> set-user and set-group ID programs..." from
> 
>   http://seclists.org/fulldisclosure/2010/Oct/257

 Ah I see. So in target we should always use absolute paths. Makes sense.

[snip]
>>>>>   I'm not entirely sure about staging, whether ld will use RPATH as an
>>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>>> not.
>>>>
>>>> So far, the patch series works for me very well. Just my usecase, of course.
>>
>>   IIRC I checked a while ago and it looked like ld would use RPATH as a link path
>> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
>> Which means that we shouldn't make the RPATHs in staging relative to
>> STAGING_DIR, otherwise it may pick up the library from the host. This really
>> shouldn't happen because the link normally should get the appropriate -L flag to
>> find the target lib and the -L has precedence over RPATH, but better be safe.
> 
> The man page of "ld" says:
> 
> "The linker uses the following search paths to locate required shared libraries:
>  ...
>  6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are
>      searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries
>      exist."

 But this doesn't clarify if these paths are interpreted relative to --sysroot
or not.

> 
> Then we should use $ORIGIN relative to the ELF file for the staging tree
> (like for the host tree) to make it relocatable.

 That is for sure the safest option.

[snip]
>>>>>> Things not yet addressed:
>>>>>>
>>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>>    to the build system (in ELF and text files).
>>>>>
>>>>>   A solution to this (and other problems) is to use the same approach as
>>>>> check-bin-arch: do it as an instrumentation hook for each package, and only look
>>>>> at the files added by that package. That way, the overhead is spread out over
>>>>> the entire build process, and doing rebuilds doesn't run patchelf on all files
>>>>> anymore in the finalize step.
>>>>
>>>> This is just to solve the issue mentioned above or a general approach (instead
>>>> of doning rtpath sanitation at the end)?
>>>
>>> Any opinions here?
>>
>>   Preferably as an instrumentation hook, because:
>> - it speeds things up dramatically if you do 'make foo-rebuild';
>> - things are still correct if you interrupt the build in the middle;
>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>> and then you rebuild a package, the RPATH in the libs you link with is different
>> than the first time you built it).
> 
> OK, as I see it, check-bin-arch is only for the files in the target tree. Having a
> closer look now.

 Yes, for this approach to work the packages-file-list has to be extended to
cover host and staging as well. And since host includes staging, the find
command for host is a little complicated.

> 
>>>> How should I go ahead to get this patch series accepted sooner than later? We
>>>> could make the option configurable, for example, to reduce the risk of
>>>> breaking something.
>>>
>>> Is a relocatable SDK still on the wish list? How should/could I proceed to get
>>> the feature accepted sooner than later?
>>
>>   You should pray that someone takes the time to continue the review :-)
>>
>>   Occasionally drawing attention to the series like you do know definitely helps.
> 
> OK, more soon...

 Next week in the Buildroot Summer Camp I'm going to spend time on this series,
so there should be progress...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >>> So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
 >>> libsudo_util.so.0 at runtime? Or how does it break?
 >> 
 >> Yep, that's the problem. I think it's because of "For security, the
 >> dynamic linker does not allow use of $ORIGIN substitution sequences for
 >> set-user and set-group ID programs..." from
 >> 
 >> http://seclists.org/fulldisclosure/2010/Oct/257

Makes sense, you don't want your setuid binaries to load random
libraries.

 >  Ah I see. So in target we should always use absolute paths. Makes sense.

Indeed.

 >  Next week in the Buildroot Summer Camp I'm going to spend time on this series,
 > so there should be progress...

Indeed. I was also planning on spending some time on it.

-- 
Bye, Peter Korsgaard

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 00:47 schrieb Arnout Vandecappelle:
> 
> 
> On 22-06-17 08:37, Wolfgang Grandegger wrote:
>> Hello Arnout,
>>
>> Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>>>    Hi Wolfgang,
>>>
>>> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>>>> Hello,
>>>>
>>>> this topic is still pending... some more input below...
>>>>
>>>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>>>> Hello Arnout,
>>>>>
>>>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>>>
>>>>>>
>>>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
> [snip]
>>>>>>> - Why do we want relative RPATHs starting with "$ORIGIN" also for ELF
>>>>>>>     files in the target tree. "/lib" and "/usr/lib" have been removed
>>>>>>>     already.
>>>>>>
>>>>>>    Good point, I don't think we want that... Neither for the ones in staging, I
>>>>>> suppose. The RPATHs there should all be absolute paths which should be
>>>>>> interpreted relative to $(TARGET_DIR) resp. $(STAGING_DIR).
>>>>>
>>>>> Could be done, no problem. Just requires some further modifications to
>>>>
>>>> I just learned that using relative path for the target breaks "sudo", at least.
>>>
>>>    So if you change sudo's RPATH to $ORIGIN/../libexec/sudo it doesn't find
>>> libsudo_util.so.0 at runtime? Or how does it break?
>>
>> Yep, that's the problem. I think it's because of "For security, the
>> dynamic linker does not allow use of $ORIGIN substitution sequences for
>> set-user and set-group ID programs..." from
>>
>>    http://seclists.org/fulldisclosure/2010/Oct/257
> 
>   Ah I see. So in target we should always use absolute paths. Makes sense.
> 
> [snip]
>>>>>>    I'm not entirely sure about staging, whether ld will use RPATH as an
>>>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>>>> not.
>>>>>
>>>>> So far, the patch series works for me very well. Just my usecase, of course.
>>>
>>>    IIRC I checked a while ago and it looked like ld would use RPATH as a link path
>>> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
>>> Which means that we shouldn't make the RPATHs in staging relative to
>>> STAGING_DIR, otherwise it may pick up the library from the host. This really
>>> shouldn't happen because the link normally should get the appropriate -L flag to
>>> find the target lib and the -L has precedence over RPATH, but better be safe.
>>
>> The man page of "ld" says:
>>
>> "The linker uses the following search paths to locate required shared libraries:
>>   ...
>>   6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH" of a shared library are
>>       searched for shared libraries needed by it. The "DT_RPATH" entries are ignored if "DT_RUNPATH" entries
>>       exist."
> 
>   But this doesn't clarify if these paths are interpreted relative to --sysroot
> or not.

I'm going to check what is in the orogilan rpath. I guess that the 
pathes are absolute to the host.

>>
>> Then we should use $ORIGIN relative to the ELF file for the staging tree
>> (like for the host tree) to make it relocatable.
> 
>   That is for sure the safest option.

BTW, like for the target, /lib and /usr/lib is removed from the rpath. 
Don't know if the linker looks into sysrot/lib or sysroot/usr/lib by 
default.

> [snip]
>>>>>>> Things not yet addressed:
>>>>>>>
>>>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>>>     to the build system (in ELF and text files).
>>>>>>
>>>>>>    A solution to this (and other problems) is to use the same approach as
>>>>>> check-bin-arch: do it as an instrumentation hook for each package, and only look
>>>>>> at the files added by that package. That way, the overhead is spread out over
>>>>>> the entire build process, and doing rebuilds doesn't run patchelf on all files
>>>>>> anymore in the finalize step.
>>>>>
>>>>> This is just to solve the issue mentioned above or a general approach (instead
>>>>> of doning rtpath sanitation at the end)?
>>>>
>>>> Any opinions here?
>>>
>>>    Preferably as an instrumentation hook, because:
>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>> - things are still correct if you interrupt the build in the middle;
>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>> and then you rebuild a package, the RPATH in the libs you link with is different
>>> than the first time you built it).
>>
>> OK, as I see it, check-bin-arch is only for the files in the target tree. Having a
>> closer look now.
> 
>   Yes, for this approach to work the packages-file-list has to be extended to
> cover host and staging as well. And since host includes staging, the find
> command for host is a little complicated.

With that approach we do not need "find" any longer. There will by a 
list of installed files per package.

>>>>> How should I go ahead to get this patch series accepted sooner than later? We
>>>>> could make the option configurable, for example, to reduce the risk of
>>>>> breaking something.
>>>>
>>>> Is a relocatable SDK still on the wish list? How should/could I proceed to get
>>>> the feature accepted sooner than later?
>>>
>>>    You should pray that someone takes the time to continue the review :-)
>>>
>>>    Occasionally drawing attention to the series like you do know definitely helps.
>>
>> OK, more soon...
> 
>   Next week in the Buildroot Summer Camp I'm going to spend time on this series,
> so there should be progress...

OK, thanks.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 28-06-17 08:45, Wolfgang Grandegger wrote:
> Am 28.06.2017 um 00:47 schrieb Arnout Vandecappelle:
>>
>>
>> On 22-06-17 08:37, Wolfgang Grandegger wrote:
>>> Hello Arnout,
>>>
>>> Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>>>>    Hi Wolfgang,
>>>>
>>>> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>>>>> Hello,
>>>>>
>>>>> this topic is still pending... some more input below...
>>>>>
>>>>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>>>>> Hello Arnout,
>>>>>>
>>>>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>>>>
>>>>>>>
>>>>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
[snip]
>>>>>>>    I'm not entirely sure about staging, whether ld will use RPATH as an
>>>>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>>>>> not.
>>>>>>
>>>>>> So far, the patch series works for me very well. Just my usecase, of course.
>>>>
>>>>    IIRC I checked a while ago and it looked like ld would use RPATH as a
>>>> link path
>>>> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
>>>> Which means that we shouldn't make the RPATHs in staging relative to
>>>> STAGING_DIR, otherwise it may pick up the library from the host. This really
>>>> shouldn't happen because the link normally should get the appropriate -L
>>>> flag to
>>>> find the target lib and the -L has precedence over RPATH, but better be safe.
>>>
>>> The man page of "ld" says:
>>>
>>> "The linker uses the following search paths to locate required shared libraries:
>>>   ...
>>>   6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH"
>>> of a shared library are
>>>       searched for shared libraries needed by it. The "DT_RPATH" entries are
>>> ignored if "DT_RUNPATH" entries
>>>       exist."
>>
>>   But this doesn't clarify if these paths are interpreted relative to --sysroot
>> or not.
> 
> I'm going to check what is in the orogilan rpath. I guess that the pathes are
> absolute to the host.

 Thinking again about this: for staging, we should probably remove RPATH completely.

* At build time, the RPATH is only used as an extra directory to search for
shared library. However, any such directory should anyway be passed with -L to
cover the static libs case. So it's better to remove the RPATH, then we see any
missing -L earlier.

* The binaries in staging should never be executed. They shouldn't be copied to
target any more. Therefore, the RPATH is never used by the dynamic linker.

 So to keep things simple and to avoid discussion about the --sysroot, I propose
to remove RPATH entirely.

> 
>>>
>>> Then we should use $ORIGIN relative to the ELF file for the staging tree
>>> (like for the host tree) to make it relocatable.
>>
>>   That is for sure the safest option.
> 
> BTW, like for the target, /lib and /usr/lib is removed from the rpath. Don't
> know if the linker looks into sysrot/lib or sysroot/usr/lib by default.
> 
>> [snip]
>>>>>>>> Things not yet addressed:
>>>>>>>>
>>>>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>>>>     to the build system (in ELF and text files).
>>>>>>>
>>>>>>>    A solution to this (and other problems) is to use the same approach as
>>>>>>> check-bin-arch: do it as an instrumentation hook for each package, and
>>>>>>> only look
>>>>>>> at the files added by that package. That way, the overhead is spread out
>>>>>>> over
>>>>>>> the entire build process, and doing rebuilds doesn't run patchelf on all
>>>>>>> files
>>>>>>> anymore in the finalize step.
>>>>>>
>>>>>> This is just to solve the issue mentioned above or a general approach
>>>>>> (instead
>>>>>> of doning rtpath sanitation at the end)?
>>>>>
>>>>> Any opinions here?
>>>>
>>>>    Preferably as an instrumentation hook, because:
>>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>>> - things are still correct if you interrupt the build in the middle;
>>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>>> and then you rebuild a package, the RPATH in the libs you link with is
>>>> different
>>>> than the first time you built it).
>>>
>>> OK, as I see it, check-bin-arch is only for the files in the target tree.
>>> Having a
>>> closer look now.
>>
>>   Yes, for this approach to work the packages-file-list has to be extended to
>> cover host and staging as well. And since host includes staging, the find
>> command for host is a little complicated.
> 
> With that approach we do not need "find" any longer. There will by a list of
> installed files per package.

 There is currently no packages-file-list for host and staging, so you need to
build it. To build the list, you need to do a find.

 Regards,
 Arnout

[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 12:41 schrieb Arnout Vandecappelle:
> 
> 
> On 28-06-17 08:45, Wolfgang Grandegger wrote:
>> Am 28.06.2017 um 00:47 schrieb Arnout Vandecappelle:
>>>
>>>
>>> On 22-06-17 08:37, Wolfgang Grandegger wrote:
>>>> Hello Arnout,
>>>>
>>>> Am 21.06.2017 um 23:03 schrieb Arnout Vandecappelle:
>>>>>     Hi Wolfgang,
>>>>>
>>>>> On 21-06-17 09:59, Wolfgang Grandegger wrote:
>>>>>> Hello,
>>>>>>
>>>>>> this topic is still pending... some more input below...
>>>>>>
>>>>>> Am 27.04.2017 um 11:37 schrieb Wolfgang Grandegger:
>>>>>>> Hello Arnout,
>>>>>>>
>>>>>>> Am 12.04.2017 um 15:59 schrieb Arnout Vandecappelle:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23-03-17 08:54, Wolfgang Grandegger wrote:
> [snip]
>>>>>>>>     I'm not entirely sure about staging, whether ld will use RPATH as an
>>>>>>>> alternative to -L and in that case whether it is done relative to sysroot or
>>>>>>>> not.
>>>>>>>
>>>>>>> So far, the patch series works for me very well. Just my usecase, of course.
>>>>>
>>>>>     IIRC I checked a while ago and it looked like ld would use RPATH as a
>>>>> link path
>>>>> (i.e. as if it's given with -L), and I think it was NOT relative to sysroot.
>>>>> Which means that we shouldn't make the RPATHs in staging relative to
>>>>> STAGING_DIR, otherwise it may pick up the library from the host. This really
>>>>> shouldn't happen because the link normally should get the appropriate -L
>>>>> flag to
>>>>> find the target lib and the -L has precedence over RPATH, but better be safe.
>>>>
>>>> The man page of "ld" says:
>>>>
>>>> "The linker uses the following search paths to locate required shared libraries:
>>>>    ...
>>>>    6.  For a native ELF linker, the directories in "DT_RUNPATH" or "DT_RPATH"
>>>> of a shared library are
>>>>        searched for shared libraries needed by it. The "DT_RPATH" entries are
>>>> ignored if "DT_RUNPATH" entries
>>>>        exist."
>>>
>>>    But this doesn't clarify if these paths are interpreted relative to --sysroot
>>> or not.
>>
>> I'm going to check what is in the orogilan rpath. I guess that the pathes are
>> absolute to the host.
> 
>   Thinking again about this: for staging, we should probably remove RPATH completely.
> 
> * At build time, the RPATH is only used as an extra directory to search for
> shared library. However, any such directory should anyway be passed with -L to
> cover the static libs case. So it's better to remove the RPATH, then we see any
> missing -L earlier.
> 
> * The binaries in staging should never be executed. They shouldn't be copied to
> target any more. Therefore, the RPATH is never used by the dynamic linker.
> 
>   So to keep things simple and to avoid discussion about the --sysroot, I propose
> to remove RPATH entirely.
> 
>>
>>>>
>>>> Then we should use $ORIGIN relative to the ELF file for the staging tree
>>>> (like for the host tree) to make it relocatable.
>>>
>>>    That is for sure the safest option.
>>
>> BTW, like for the target, /lib and /usr/lib is removed from the rpath. Don't
>> know if the linker looks into sysrot/lib or sysroot/usr/lib by default.
>>
>>> [snip]
>>>>>>>>> Things not yet addressed:
>>>>>>>>>
>>>>>>>>> - "make toolchain" creates a toolchain tree which still has references
>>>>>>>>>      to the build system (in ELF and text files).
>>>>>>>>
>>>>>>>>     A solution to this (and other problems) is to use the same approach as
>>>>>>>> check-bin-arch: do it as an instrumentation hook for each package, and
>>>>>>>> only look
>>>>>>>> at the files added by that package. That way, the overhead is spread out
>>>>>>>> over
>>>>>>>> the entire build process, and doing rebuilds doesn't run patchelf on all
>>>>>>>> files
>>>>>>>> anymore in the finalize step.
>>>>>>>
>>>>>>> This is just to solve the issue mentioned above or a general approach
>>>>>>> (instead
>>>>>>> of doning rtpath sanitation at the end)?
>>>>>>
>>>>>> Any opinions here?
>>>>>
>>>>>     Preferably as an instrumentation hook, because:
>>>>> - it speeds things up dramatically if you do 'make foo-rebuild';
>>>>> - things are still correct if you interrupt the build in the middle;
>>>>> - it makes no difference if you do a rebuild (if patchelf is done at the end,
>>>>> and then you rebuild a package, the RPATH in the libs you link with is
>>>>> different
>>>>> than the first time you built it).
>>>>
>>>> OK, as I see it, check-bin-arch is only for the files in the target tree.
>>>> Having a
>>>> closer look now.
>>>
>>>    Yes, for this approach to work the packages-file-list has to be extended to
>>> cover host and staging as well. And since host includes staging, the find
>>> command for host is a little complicated.
>>
>> With that approach we do not need "find" any longer. There will by a list of
>> installed files per package.
> 
>   There is currently no packages-file-list for host and staging, so you need to
> build it. To build the list, you need to do a find.

The list is built with "comm -13 ...". While implementing that way, I 
realized that I need patchelf for the host as very first package. Any 
idea how that could achieved?

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 28-06-17 12:57, Wolfgang Grandegger wrote:
[snip]
> The list is built with "comm -13 ...". While implementing that way, I realized
> that I need patchelf for the host as very first package. Any idea how that could
> achieved?

 host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it gets built
before all the rest. In the instrumentation hook, you should also skip the
sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.

 That means that those packages will not get sanitized - which shouldn't be
necessary since they anyway don't have an rpath. But perhaps it's a good idea
then to add a readelf-based check for them that verifies they don't have
DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, so don't
worry about it at first.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
> 
> 
> On 28-06-17 12:57, Wolfgang Grandegger wrote:
> [snip]
>> The list is built with "comm -13 ...". While implementing that way, I realized
>> that I need patchelf for the host as very first package. Any idea how that could
>> achieved?
> 
>   host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it gets built
> before all the rest. In the instrumentation hook, you should also skip the
> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.

I thought all host binaries must have an rpath to <path>/usr/lib, which 
should be replaced with "$ORIGIN/../../../usr/lib"

>   That means that those packages will not get sanitized - which shouldn't be
> necessary since they anyway don't have an rpath. But perhaps it's a good idea
> then to add a readelf-based check for them that verifies they don't have
> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, so don't
> worry about it at first.

See above.

Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first 
place, some packages are required in advance to build patchelf :(.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 28-06-17 14:36, Wolfgang Grandegger wrote:
> 
> 
> Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
>>
>>
>> On 28-06-17 12:57, Wolfgang Grandegger wrote:
>> [snip]
>>> The list is built with "comm -13 ...". While implementing that way, I realized
>>> that I need patchelf for the host as very first package. Any idea how that could
>>> achieved?
>>
>>   host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it gets built
>> before all the rest. In the instrumentation hook, you should also skip the
>> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.
> 
> I thought all host binaries must have an rpath to <path>/usr/lib, which should
> be replaced with "$ORIGIN/../../../usr/lib"

 Only if they use a library in $HOST_DIR/usr/lib - otherwise sanitize-rpath will
remove the rpatch completely, no?

 DEPENDENCIES_HOST_PREREQ contains only a few packages, none of which are linked
with any library in $HOST_DIR/usr/lib. At least I think so.


>>   That means that those packages will not get sanitized - which shouldn't be
>> necessary since they anyway don't have an rpath. But perhaps it's a good idea
>> then to add a readelf-based check for them that verifies they don't have
>> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, so don't
>> worry about it at first.
> 
> See above.
> 
> Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first place, some
> packages are required in advance to build patchelf :(.

 Really? Which ones? patchelf has no dependencies.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Am 28.06.2017 um 21:33 schrieb Arnout Vandecappelle:
> 
> 
> On 28-06-17 14:36, Wolfgang Grandegger wrote:
>>
>>
>> Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
>>>
>>>
>>> On 28-06-17 12:57, Wolfgang Grandegger wrote:
>>> [snip]
>>>> The list is built with "comm -13 ...". While implementing that way, I realized
>>>> that I need patchelf for the host as very first package. Any idea how that could
>>>> achieved?
>>>
>>>    host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it gets built
>>> before all the rest. In the instrumentation hook, you should also skip the
>>> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.
>>
>> I thought all host binaries must have an rpath to <path>/usr/lib, which should
>> be replaced with "$ORIGIN/../../../usr/lib"
> 
>   Only if they use a library in $HOST_DIR/usr/lib - otherwise sanitize-rpath will
> remove the rpatch completely, no?

Makes sense.

>   DEPENDENCIES_HOST_PREREQ contains only a few packages, none of which are linked
> with any library in $HOST_DIR/usr/lib. At least I think so.

In may case it only contains "patchelf", which needs rpath sanitation.

>>>    That means that those packages will not get sanitized - which shouldn't be
>>> necessary since they anyway don't have an rpath. But perhaps it's a good idea
>>> then to add a readelf-based check for them that verifies they don't have
>>> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, so don't
>>> worry about it at first.
>>
>> See above.
>>
>> Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first place, some
>> packages are required in advance to build patchelf :(.
> 
>   Really? Which ones? patchelf has no dependencies.

   host-m4-1.4.18
   host-libtool-2.4.6
   host-autoconf-2.69
   host-automake-1.15
   host-patchelf-29c085fd9d3fc972f75b3961905d6b4ecce7eb2b

Here is the order in which the packages are built. Patchelf needs 
automake and friends. The "host-m4" binary m4 has an rpath;

<buildroot-build-dir>/host/usr/lib

The others have perl scripts only. Hence, we need to sanitize the 
"host-m4" package after patchelf is available. Not too bad.

Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello Arnout,

about rpath sanitazion of patchelf and m4...

Am 29.06.2017 um 08:13 schrieb Wolfgang Grandegger:
> 
> 
> Am 28.06.2017 um 21:33 schrieb Arnout Vandecappelle:
>>
>>
>> On 28-06-17 14:36, Wolfgang Grandegger wrote:
>>>
>>>
>>> Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
>>>>
>>>>
>>>> On 28-06-17 12:57, Wolfgang Grandegger wrote:
>>>> [snip]
>>>>> The list is built with "comm -13 ...". While implementing that way, 
>>>>> I realized
>>>>> that I need patchelf for the host as very first package. Any idea 
>>>>> how that could
>>>>> achieved?
>>>>
>>>>    host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it 
>>>> gets built
>>>> before all the rest. In the instrumentation hook, you should also 
>>>> skip the
>>>> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.
>>>
>>> I thought all host binaries must have an rpath to <path>/usr/lib, 
>>> which should
>>> be replaced with "$ORIGIN/../../../usr/lib"
>>
>>   Only if they use a library in $HOST_DIR/usr/lib - otherwise 
>> sanitize-rpath will
>> remove the rpatch completely, no?
> 
> Makes sense.
> 
>>   DEPENDENCIES_HOST_PREREQ contains only a few packages, none of which 
>> are linked
>> with any library in $HOST_DIR/usr/lib. At least I think so.
> 
> In may case it only contains "patchelf", which needs rpath sanitation.
> 
>>>>    That means that those packages will not get sanitized - which 
>>>> shouldn't be
>>>> necessary since they anyway don't have an rpath. But perhaps it's a 
>>>> good idea
>>>> then to add a readelf-based check for them that verifies they don't 
>>>> have
>>>> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, 
>>>> so don't
>>>> worry about it at first.
>>>
>>> See above.
>>>
>>> Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first 
>>> place, some
>>> packages are required in advance to build patchelf :(.
>>
>>   Really? Which ones? patchelf has no dependencies.
> 
>    host-m4-1.4.18
>    host-libtool-2.4.6
>    host-autoconf-2.69
>    host-automake-1.15
>    host-patchelf-29c085fd9d3fc972f75b3961905d6b4ecce7eb2b
> 
> Here is the order in which the packages are built. Patchelf needs 
> automake and friends. The "host-m4" binary m4 has an rpath;
> 
> <buildroot-build-dir>/host/usr/lib
> 
> The others have perl scripts only. Hence, we need to sanitize the 
> "host-m4" package after patchelf is available. Not too bad.

Neither patchelf nor m4 uses libraries from /usr/lib and therefore the 
rpath is empty. A mistake in my scripts confused me... sorry for the noise.

Wolfgang.

> 
> Wolfgang.

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello,

Am 29.06.2017 um 10:02 schrieb Wolfgang Grandegger:
> Hello Arnout,
> 
> about rpath sanitazion of patchelf and m4...
> 
> Am 29.06.2017 um 08:13 schrieb Wolfgang Grandegger:
>>
>>
>> Am 28.06.2017 um 21:33 schrieb Arnout Vandecappelle:
>>>
>>>
>>> On 28-06-17 14:36, Wolfgang Grandegger wrote:
>>>>
>>>>
>>>> Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
>>>>>
>>>>>
>>>>> On 28-06-17 12:57, Wolfgang Grandegger wrote:
>>>>> [snip]
>>>>>> The list is built with "comm -13 ...". While implementing that 
>>>>>> way, I realized
>>>>>> that I need patchelf for the host as very first package. Any idea 
>>>>>> how that could
>>>>>> achieved?
>>>>>
>>>>>    host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it 
>>>>> gets built
>>>>> before all the rest. In the instrumentation hook, you should also 
>>>>> skip the
>>>>> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.
>>>>
>>>> I thought all host binaries must have an rpath to <path>/usr/lib, 
>>>> which should
>>>> be replaced with "$ORIGIN/../../../usr/lib"
>>>
>>>   Only if they use a library in $HOST_DIR/usr/lib - otherwise 
>>> sanitize-rpath will
>>> remove the rpatch completely, no?
>>
>> Makes sense.
>>
>>>   DEPENDENCIES_HOST_PREREQ contains only a few packages, none of 
>>> which are linked
>>> with any library in $HOST_DIR/usr/lib. At least I think so.
>>
>> In may case it only contains "patchelf", which needs rpath sanitation.
>>
>>>>>    That means that those packages will not get sanitized - which 
>>>>> shouldn't be
>>>>> necessary since they anyway don't have an rpath. But perhaps it's a 
>>>>> good idea
>>>>> then to add a readelf-based check for them that verifies they don't 
>>>>> have
>>>>> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though, 
>>>>> so don't
>>>>> worry about it at first.
>>>>
>>>> See above.
>>>>
>>>> Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first 
>>>> place, some
>>>> packages are required in advance to build patchelf :(.
>>>
>>>   Really? Which ones? patchelf has no dependencies.
>>
>>    host-m4-1.4.18
>>    host-libtool-2.4.6
>>    host-autoconf-2.69
>>    host-automake-1.15
>>    host-patchelf-29c085fd9d3fc972f75b3961905d6b4ecce7eb2b
>>
>> Here is the order in which the packages are built. Patchelf needs 
>> automake and friends. The "host-m4" binary m4 has an rpath;
>>
>> <buildroot-build-dir>/host/usr/lib
>>
>> The others have perl scripts only. Hence, we need to sanitize the 
>> "host-m4" package after patchelf is available. Not too bad.
> 
> Neither patchelf nor m4 uses libraries from /usr/lib and therefore the 
> rpath is empty. A mistake in my scripts confused me... sorry for the noise.

I must again correct myself :(. Both binaries have 
"<buildroot-build-dir>/host/usr/lib" in their rpath after the build step and
the sanitation will remove it:

  patching ELF file '/home/wolf/test/bdo/imx6ulpico/host/usr/bin/patchelf'
  removing directory '/home/wolf/test/bdo/imx6ulpico/host/usr/lib' from RPATH because it does not contain needed libs
  new rpath is ''

I have just sent out a new patch series doing the sanitation per
package and build step. It will use "--debug" to show the sanitation
results. I have attached the "rpath-sanitation-imx6ulpico.log" output
to show what sanitation is doing for "imx6ulpico_defconfig" with
"glibc", "sudo" and "pulseaudio". Some quick observations:

- It removes "/usr/lib" from most host binaries because it does not
  contain needed libs. It uses "$ORIGIN/../../usr/lib" otherwise.

- It clears the RPATH for most target binaries. Only a few remain,
  e.g. for the "sudo" and "pulseaudio" package (not pointing to
  "/lib" or "/usr/lib".

Concerning that topic, I also realized that "readelf" is used with
"regexp" heavily. I think using "patchelf" for that purpose would be
faster.

Then happy hacking at the Summer Camp.

Wolfgang.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpath-sanitation-imx6ulpico.log
Type: text/x-log
Size: 182714 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170630/a873e4e9/attachment.bin>

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Wolfgang Grandegger]

Hello, just another observation...


$ find . -name '.br_host_filelist'|xargs grep sysroot
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libgcc_s.so.1
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.a
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.so.1.2.0
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.a
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.so.6.0.22
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.la
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.so.6.0.22-gdb.py
./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libgcc_s.so

GCC seems to install into "sysroot" in the "install-host" step. Not
sure if this is a problem (needs special treatment).

Wolfgang.

Am 30.06.2017 um 10:50 schrieb Wolfgang Grandegger:
> Hello,
> 
> Am 29.06.2017 um 10:02 schrieb Wolfgang Grandegger:
>> Hello Arnout,
>>
>> about rpath sanitazion of patchelf and m4...
>>
>> Am 29.06.2017 um 08:13 schrieb Wolfgang Grandegger:
>>>
>>>
>>> Am 28.06.2017 um 21:33 schrieb Arnout Vandecappelle:
>>>>
>>>>
>>>> On 28-06-17 14:36, Wolfgang Grandegger wrote:
>>>>>
>>>>>
>>>>> Am 28.06.2017 um 13:16 schrieb Arnout Vandecappelle:
>>>>>>
>>>>>>
>>>>>> On 28-06-17 12:57, Wolfgang Grandegger wrote:
>>>>>> [snip]
>>>>>>> The list is built with "comm -13 ...". While implementing that
>>>>>>> way, I realized
>>>>>>> that I need patchelf for the host as very first package. Any idea
>>>>>>> how that could
>>>>>>> achieved?
>>>>>>
>>>>>>     host-patchelf should be added to DEPENDENCIES_HOST_PREREQ so it
>>>>>> gets built
>>>>>> before all the rest. In the instrumentation hook, you should also
>>>>>> skip the
>>>>>> sanitization when the package is not in DEPENDENCIES_HOST_PREREQ.
>>>>>
>>>>> I thought all host binaries must have an rpath to <path>/usr/lib,
>>>>> which should
>>>>> be replaced with "$ORIGIN/../../../usr/lib"
>>>>
>>>>    Only if they use a library in $HOST_DIR/usr/lib - otherwise
>>>> sanitize-rpath will
>>>> remove the rpatch completely, no?
>>>
>>> Makes sense.
>>>
>>>>    DEPENDENCIES_HOST_PREREQ contains only a few packages, none of
>>>> which are linked
>>>> with any library in $HOST_DIR/usr/lib. At least I think so.
>>>
>>> In may case it only contains "patchelf", which needs rpath sanitation.
>>>
>>>>>>     That means that those packages will not get sanitized - which
>>>>>> shouldn't be
>>>>>> necessary since they anyway don't have an rpath. But perhaps it's a
>>>>>> good idea
>>>>>> then to add a readelf-based check for them that verifies they don't
>>>>>> have
>>>>>> DT_RUNPATH or DT_RPATH. The latter is just a nice-to-have, though,
>>>>>> so don't
>>>>>> worry about it at first.
>>>>>
>>>>> See above.
>>>>>
>>>>> Even with setting DEPENDENCIES_HOST_PREREQ to patchelf at the first
>>>>> place, some
>>>>> packages are required in advance to build patchelf :(.
>>>>
>>>>    Really? Which ones? patchelf has no dependencies.
>>>
>>>     host-m4-1.4.18
>>>     host-libtool-2.4.6
>>>     host-autoconf-2.69
>>>     host-automake-1.15
>>>     host-patchelf-29c085fd9d3fc972f75b3961905d6b4ecce7eb2b
>>>
>>> Here is the order in which the packages are built. Patchelf needs
>>> automake and friends. The "host-m4" binary m4 has an rpath;
>>>
>>> <buildroot-build-dir>/host/usr/lib
>>>
>>> The others have perl scripts only. Hence, we need to sanitize the
>>> "host-m4" package after patchelf is available. Not too bad.
>>
>> Neither patchelf nor m4 uses libraries from /usr/lib and therefore the
>> rpath is empty. A mistake in my scripts confused me... sorry for the noise.
> 
> I must again correct myself :(. Both binaries have
> "<buildroot-build-dir>/host/usr/lib" in their rpath after the build step and
> the sanitation will remove it:
> 
>    patching ELF file '/home/wolf/test/bdo/imx6ulpico/host/usr/bin/patchelf'
>    removing directory '/home/wolf/test/bdo/imx6ulpico/host/usr/lib' from RPATH because it does not contain needed libs
>    new rpath is ''
> 
> I have just sent out a new patch series doing the sanitation per
> package and build step. It will use "--debug" to show the sanitation
> results. I have attached the "rpath-sanitation-imx6ulpico.log" output
> to show what sanitation is doing for "imx6ulpico_defconfig" with
> "glibc", "sudo" and "pulseaudio". Some quick observations:
> 
> - It removes "/usr/lib" from most host binaries because it does not
>    contain needed libs. It uses "$ORIGIN/../../usr/lib" otherwise.
> 
> - It clears the RPATH for most target binaries. Only a few remain,
>    e.g. for the "sudo" and "pulseaudio" package (not pointing to
>    "/lib" or "/usr/lib".
> 
> Concerning that topic, I also realized that "readelf" is used with
> "regexp" heavily. I think using "patchelf" for that purpose would be
> faster.
> 
> Then happy hacking at the Summer Camp.
> 
> Wolfgang.
> 
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] [RFC PATCH v3 00/10] Make the SDK relocatable

[Arnout Vandecappelle]

On 30-06-17 11:14, Wolfgang Grandegger wrote:
> Hello, just another observation...
> 
> 
> $ find . -name '.br_host_filelist'|xargs grep sysroot
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libgcc_s.so.1
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.a
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.so.1.2.0
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.a
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.so.6.0.22
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libatomic.la
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.so.6.0.22-gdb.py
> ./build/host-gcc-final-6.3.0/.br_host_filelist:usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libgcc_s.so
> 
> GCC seems to install into "sysroot" in the "install-host" step. Not
> sure if this is a problem (needs special treatment).

 Good observation! I'll have to think about that one...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF