kumquat-buildroot/support/scripts/check-host-rpath

112 lines
4.2 KiB
Plaintext
Raw Normal View History

core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
#!/usr/bin/env bash
# This script scans $(HOST_DIR)/{bin,sbin} for all ELF files, and checks
# they have an RPATH to $(HOST_DIR)/lib if they need libraries from
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
# there.
# Override the user's locale so we are sure we can parse the output of
# readelf(1) and file(1)
export LC_ALL=C
main() {
local pkg="${1}"
local hostdir="${2}"
core: implement per-package SDK and target This commit implements the core of the move to per-package SDK and target directories. The main idea is that instead of having a global output/host and output/target in which all packages install files, we switch to per-package host and target directories, that only contain their explicit dependencies. There are two main benefits: - Packages will now see only the dependencies they explicitly list in their <pkg>_DEPENDENCIES variable, and the recursive dependencies thereof. - We can support top-level parallel build properly, because a package only "sees" its own host directory and target directory, isolated from the build of other packages that can happen in parallel. It works as follows: - A new output/per-package/ directory is created, which will contain one sub-directory per package, and inside it, a "host" directory and a "target" directory: output/per-package/busybox/target output/per-package/busybox/host output/per-package/host-fakeroot/target output/per-package/host-fakeroot/host This output/per-package/ directory is PER_PACKAGE_DIR. - The global TARGET_DIR and HOST_DIR variable now automatically point to the per-package directory when PKG is defined. So whenever a package references $(HOST_DIR) or $(TARGET_DIR) in its build process, it effectively references the per-package host/target directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it is handled as well. - Of course, packages have dependencies, so those dependencies must be installed in the per-package host and target directories. To do so, we simply rsync (using hard links to save space and time) the host and target directories of the direct dependencies of the package to the current package host and target directories. We only need to take care of direct dependencies (and not recursively all dependencies), because we accumulate into those per-package host and target directories the files installed by the dependencies. Note that this only works because we make the assumption that one package does *not* overwrite files installed by another package. This is done for "extract dependencies" at the beginning of the extract step, and for "normal dependencies" at the beginning of the configure step. This is basically enough to make per-package SDK and target work. The only gotcha is that at the end of the build, output/target and output/host are empty, which means that: - The filesystem image creation code cannot work. - We don't have a SDK to build code outside of Buildroot. In order to fix this, this commit extends the target-finalize step so that it starts by populating output/target and output/host by rsync-ing into them the target and host directories of all packages listed in the $(PACKAGES) variable. It is necessary to do this sequentially in the target-finalize step and not in each package. Doing it in package installation means that it can be done in parallel. In that case, there is a chance that two rsyncs are creating the same hardlink or directory at the same time, which makes one of them fail. This change to per-package directories has an impact on the RPATH built into the host binaries, as those RPATH now point to various per-package host directories, and no longer to the global host directory. We do not try to rewrite such RPATHs during the build as having such RPATHs is perfectly fine, but we still need to handle two fallouts from this change: - The check-host-rpath script, which verifies at the end of each package installation that it has the appropriate RPATH, is modified to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is a correct RPAT. - The fix-rpath script, which mungles the RPATH mainly for the SDK preparation, is modified to rewrite the RPATH to not point to per-package directories. Indeed the patchelf --make-rpath-relative call only works if the RPATH points to the ROOTDIR passed as argument, and this ROOTDIR is the global host directory. Rewriting the RPATH to not point to per-package host directories prior to this is an easy solution to this issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
local perpackagedir="${3}"
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
local file ret
# Remove duplicate and trailing '/' for proper match
hostdir="$( sed -r -e 's:/+:/:g; s:/$::;' <<<"${hostdir}" )"
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
ret=0
while read file; do
is_elf "${file}" || continue
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
elf_needs_rpath "${file}" "${hostdir}" || continue
core: implement per-package SDK and target This commit implements the core of the move to per-package SDK and target directories. The main idea is that instead of having a global output/host and output/target in which all packages install files, we switch to per-package host and target directories, that only contain their explicit dependencies. There are two main benefits: - Packages will now see only the dependencies they explicitly list in their <pkg>_DEPENDENCIES variable, and the recursive dependencies thereof. - We can support top-level parallel build properly, because a package only "sees" its own host directory and target directory, isolated from the build of other packages that can happen in parallel. It works as follows: - A new output/per-package/ directory is created, which will contain one sub-directory per package, and inside it, a "host" directory and a "target" directory: output/per-package/busybox/target output/per-package/busybox/host output/per-package/host-fakeroot/target output/per-package/host-fakeroot/host This output/per-package/ directory is PER_PACKAGE_DIR. - The global TARGET_DIR and HOST_DIR variable now automatically point to the per-package directory when PKG is defined. So whenever a package references $(HOST_DIR) or $(TARGET_DIR) in its build process, it effectively references the per-package host/target directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it is handled as well. - Of course, packages have dependencies, so those dependencies must be installed in the per-package host and target directories. To do so, we simply rsync (using hard links to save space and time) the host and target directories of the direct dependencies of the package to the current package host and target directories. We only need to take care of direct dependencies (and not recursively all dependencies), because we accumulate into those per-package host and target directories the files installed by the dependencies. Note that this only works because we make the assumption that one package does *not* overwrite files installed by another package. This is done for "extract dependencies" at the beginning of the extract step, and for "normal dependencies" at the beginning of the configure step. This is basically enough to make per-package SDK and target work. The only gotcha is that at the end of the build, output/target and output/host are empty, which means that: - The filesystem image creation code cannot work. - We don't have a SDK to build code outside of Buildroot. In order to fix this, this commit extends the target-finalize step so that it starts by populating output/target and output/host by rsync-ing into them the target and host directories of all packages listed in the $(PACKAGES) variable. It is necessary to do this sequentially in the target-finalize step and not in each package. Doing it in package installation means that it can be done in parallel. In that case, there is a chance that two rsyncs are creating the same hardlink or directory at the same time, which makes one of them fail. This change to per-package directories has an impact on the RPATH built into the host binaries, as those RPATH now point to various per-package host directories, and no longer to the global host directory. We do not try to rewrite such RPATHs during the build as having such RPATHs is perfectly fine, but we still need to handle two fallouts from this change: - The check-host-rpath script, which verifies at the end of each package installation that it has the appropriate RPATH, is modified to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is a correct RPAT. - The fix-rpath script, which mungles the RPATH mainly for the SDK preparation, is modified to rewrite the RPATH to not point to per-package directories. Indeed the patchelf --make-rpath-relative call only works if the RPATH points to the ROOTDIR passed as argument, and this ROOTDIR is the global host directory. Rewriting the RPATH to not point to per-package host directories prior to this is an easy solution to this issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
check_elf_has_rpath "${file}" "${hostdir}" "${perpackagedir}" && continue
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
if [ ${ret} -eq 0 ]; then
ret=1
printf "***\n"
printf "*** ERROR: package %s installs executables without proper RPATH:\n" "${pkg}"
fi
printf "*** %s\n" "${file}"
done < <( find "${hostdir}"/{bin,sbin} -type f 2>/dev/null )
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
return ${ret}
}
is_elf() {
local f="${1}"
readelf -l "${f}" 2>/dev/null \
|grep -E 'Requesting program interpreter:' >/dev/null 2>&1
}
# This function tells whether a given ELF executable (first argument)
# needs a RPATH pointing to the host library directory or not. It
# needs such an RPATH if at least of the libraries used by the ELF
# executable is available in the host library directory. This function
# returns 0 when a RPATH is needed, 1 otherwise.
core: implement per-package SDK and target This commit implements the core of the move to per-package SDK and target directories. The main idea is that instead of having a global output/host and output/target in which all packages install files, we switch to per-package host and target directories, that only contain their explicit dependencies. There are two main benefits: - Packages will now see only the dependencies they explicitly list in their <pkg>_DEPENDENCIES variable, and the recursive dependencies thereof. - We can support top-level parallel build properly, because a package only "sees" its own host directory and target directory, isolated from the build of other packages that can happen in parallel. It works as follows: - A new output/per-package/ directory is created, which will contain one sub-directory per package, and inside it, a "host" directory and a "target" directory: output/per-package/busybox/target output/per-package/busybox/host output/per-package/host-fakeroot/target output/per-package/host-fakeroot/host This output/per-package/ directory is PER_PACKAGE_DIR. - The global TARGET_DIR and HOST_DIR variable now automatically point to the per-package directory when PKG is defined. So whenever a package references $(HOST_DIR) or $(TARGET_DIR) in its build process, it effectively references the per-package host/target directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it is handled as well. - Of course, packages have dependencies, so those dependencies must be installed in the per-package host and target directories. To do so, we simply rsync (using hard links to save space and time) the host and target directories of the direct dependencies of the package to the current package host and target directories. We only need to take care of direct dependencies (and not recursively all dependencies), because we accumulate into those per-package host and target directories the files installed by the dependencies. Note that this only works because we make the assumption that one package does *not* overwrite files installed by another package. This is done for "extract dependencies" at the beginning of the extract step, and for "normal dependencies" at the beginning of the configure step. This is basically enough to make per-package SDK and target work. The only gotcha is that at the end of the build, output/target and output/host are empty, which means that: - The filesystem image creation code cannot work. - We don't have a SDK to build code outside of Buildroot. In order to fix this, this commit extends the target-finalize step so that it starts by populating output/target and output/host by rsync-ing into them the target and host directories of all packages listed in the $(PACKAGES) variable. It is necessary to do this sequentially in the target-finalize step and not in each package. Doing it in package installation means that it can be done in parallel. In that case, there is a chance that two rsyncs are creating the same hardlink or directory at the same time, which makes one of them fail. This change to per-package directories has an impact on the RPATH built into the host binaries, as those RPATH now point to various per-package host directories, and no longer to the global host directory. We do not try to rewrite such RPATHs during the build as having such RPATHs is perfectly fine, but we still need to handle two fallouts from this change: - The check-host-rpath script, which verifies at the end of each package installation that it has the appropriate RPATH, is modified to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is a correct RPAT. - The fix-rpath script, which mungles the RPATH mainly for the SDK preparation, is modified to rewrite the RPATH to not point to per-package directories. Indeed the patchelf --make-rpath-relative call only works if the RPATH points to the ROOTDIR passed as argument, and this ROOTDIR is the global host directory. Rewriting the RPATH to not point to per-package host directories prior to this is an easy solution to this issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
#
# With per-package directory support, ${hostdir} will point to the
# current package per-package host directory, and this is where this
# function will check if the libraries needed by the executable are
# located (or not). In practice, the ELF executable RPATH may point to
# another package per-package host directory, but that is fine because
# if such an executable is within the current package per-package host
# directory, its libraries will also have been copied into the current
# package per-package host directory.
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
elf_needs_rpath() {
local file="${1}"
local hostdir="${2}"
local lib
while read lib; do
[ -e "${hostdir}/lib/${lib}" ] && return 0
support/scripts/check-host-rpath: send readelf error output to oblivion Somewhere between binutils 2.35 and 2.37, some functionality was added in readelf to parse more DWARF information. Unfortunately, as reported in binutils bug 28981 ("https://sourceware.org/bugzilla/show_bug.cgi?id=28981"), this feature causes a number of fairly scary warnings to be displayed when running readelf on binaries built with Clang, such as the pre-built rustc and rustdoc binaries part of the host-rust-bin package. It looks like this: readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 2f in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 10b in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 10c in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Further warnings about bogus end-of-sibling markers suppressed readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: DIE at offset 0x1da refers to abbreviation number 5827 which does not exist These warnings are caused by the readelf calls done by the support/scripts/check-host-rpath script. The annoying thing is that once host-rust-bin has been installed in $(HOST_DIR), this warning appears after the installation of every single host package, because support/scripts/check-host-rpath rescans all binaries every time. To avoid showing those scary warnings, this commit sends the error output of readelf to /dev/null. Of course, it would be nicer to only filter out those warnings, but filtering the error output without merging the error output into the standard output is tricky, so let's keep things simple. If there is really an error, readelf will abort. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-27 12:47:51 +02:00
done < <( readelf -d "${file}" 2>/dev/null \
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
|sed -r -e '/^.* \(NEEDED\) .*Shared library: \[(.+)\]$/!d;' \
-e 's//\1/;' \
)
return 1
}
# This function checks whether at least one of the RPATH of the given
# ELF executable (first argument) properly points to the host library
# directory (second argument), either through an absolute RPATH or a
core: implement per-package SDK and target This commit implements the core of the move to per-package SDK and target directories. The main idea is that instead of having a global output/host and output/target in which all packages install files, we switch to per-package host and target directories, that only contain their explicit dependencies. There are two main benefits: - Packages will now see only the dependencies they explicitly list in their <pkg>_DEPENDENCIES variable, and the recursive dependencies thereof. - We can support top-level parallel build properly, because a package only "sees" its own host directory and target directory, isolated from the build of other packages that can happen in parallel. It works as follows: - A new output/per-package/ directory is created, which will contain one sub-directory per package, and inside it, a "host" directory and a "target" directory: output/per-package/busybox/target output/per-package/busybox/host output/per-package/host-fakeroot/target output/per-package/host-fakeroot/host This output/per-package/ directory is PER_PACKAGE_DIR. - The global TARGET_DIR and HOST_DIR variable now automatically point to the per-package directory when PKG is defined. So whenever a package references $(HOST_DIR) or $(TARGET_DIR) in its build process, it effectively references the per-package host/target directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it is handled as well. - Of course, packages have dependencies, so those dependencies must be installed in the per-package host and target directories. To do so, we simply rsync (using hard links to save space and time) the host and target directories of the direct dependencies of the package to the current package host and target directories. We only need to take care of direct dependencies (and not recursively all dependencies), because we accumulate into those per-package host and target directories the files installed by the dependencies. Note that this only works because we make the assumption that one package does *not* overwrite files installed by another package. This is done for "extract dependencies" at the beginning of the extract step, and for "normal dependencies" at the beginning of the configure step. This is basically enough to make per-package SDK and target work. The only gotcha is that at the end of the build, output/target and output/host are empty, which means that: - The filesystem image creation code cannot work. - We don't have a SDK to build code outside of Buildroot. In order to fix this, this commit extends the target-finalize step so that it starts by populating output/target and output/host by rsync-ing into them the target and host directories of all packages listed in the $(PACKAGES) variable. It is necessary to do this sequentially in the target-finalize step and not in each package. Doing it in package installation means that it can be done in parallel. In that case, there is a chance that two rsyncs are creating the same hardlink or directory at the same time, which makes one of them fail. This change to per-package directories has an impact on the RPATH built into the host binaries, as those RPATH now point to various per-package host directories, and no longer to the global host directory. We do not try to rewrite such RPATHs during the build as having such RPATHs is perfectly fine, but we still need to handle two fallouts from this change: - The check-host-rpath script, which verifies at the end of each package installation that it has the appropriate RPATH, is modified to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is a correct RPAT. - The fix-rpath script, which mungles the RPATH mainly for the SDK preparation, is modified to rewrite the RPATH to not point to per-package directories. Indeed the patchelf --make-rpath-relative call only works if the RPATH points to the ROOTDIR passed as argument, and this ROOTDIR is the global host directory. Rewriting the RPATH to not point to per-package host directories prior to this is an easy solution to this issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
# relative RPATH. In the context of per-package directory support,
# ${hostdir} (second argument) points to the current package host
# directory. However, it is perfectly valid for an ELF binary to have
# a RPATH pointing to another package per-package host directory,
# which is why such RPATH is also accepted (the per-package directory
# gets passed as third argument). Having a RPATH pointing to the host
# directory will make sure the ELF executable will find at runtime the
# shared libraries it depends on. This function returns 0 when a
# proper RPATH was found, or 1 otherwise.
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
check_elf_has_rpath() {
local file="${1}"
local hostdir="${2}"
core: implement per-package SDK and target This commit implements the core of the move to per-package SDK and target directories. The main idea is that instead of having a global output/host and output/target in which all packages install files, we switch to per-package host and target directories, that only contain their explicit dependencies. There are two main benefits: - Packages will now see only the dependencies they explicitly list in their <pkg>_DEPENDENCIES variable, and the recursive dependencies thereof. - We can support top-level parallel build properly, because a package only "sees" its own host directory and target directory, isolated from the build of other packages that can happen in parallel. It works as follows: - A new output/per-package/ directory is created, which will contain one sub-directory per package, and inside it, a "host" directory and a "target" directory: output/per-package/busybox/target output/per-package/busybox/host output/per-package/host-fakeroot/target output/per-package/host-fakeroot/host This output/per-package/ directory is PER_PACKAGE_DIR. - The global TARGET_DIR and HOST_DIR variable now automatically point to the per-package directory when PKG is defined. So whenever a package references $(HOST_DIR) or $(TARGET_DIR) in its build process, it effectively references the per-package host/target directories. Note that STAGING_DIR is a sub-dir of HOST_DIR, so it is handled as well. - Of course, packages have dependencies, so those dependencies must be installed in the per-package host and target directories. To do so, we simply rsync (using hard links to save space and time) the host and target directories of the direct dependencies of the package to the current package host and target directories. We only need to take care of direct dependencies (and not recursively all dependencies), because we accumulate into those per-package host and target directories the files installed by the dependencies. Note that this only works because we make the assumption that one package does *not* overwrite files installed by another package. This is done for "extract dependencies" at the beginning of the extract step, and for "normal dependencies" at the beginning of the configure step. This is basically enough to make per-package SDK and target work. The only gotcha is that at the end of the build, output/target and output/host are empty, which means that: - The filesystem image creation code cannot work. - We don't have a SDK to build code outside of Buildroot. In order to fix this, this commit extends the target-finalize step so that it starts by populating output/target and output/host by rsync-ing into them the target and host directories of all packages listed in the $(PACKAGES) variable. It is necessary to do this sequentially in the target-finalize step and not in each package. Doing it in package installation means that it can be done in parallel. In that case, there is a chance that two rsyncs are creating the same hardlink or directory at the same time, which makes one of them fail. This change to per-package directories has an impact on the RPATH built into the host binaries, as those RPATH now point to various per-package host directories, and no longer to the global host directory. We do not try to rewrite such RPATHs during the build as having such RPATHs is perfectly fine, but we still need to handle two fallouts from this change: - The check-host-rpath script, which verifies at the end of each package installation that it has the appropriate RPATH, is modified to understand that a RPATH to $(PER_PACKAGE_DIR)/<pkg>/host/lib is a correct RPAT. - The fix-rpath script, which mungles the RPATH mainly for the SDK preparation, is modified to rewrite the RPATH to not point to per-package directories. Indeed the patchelf --make-rpath-relative call only works if the RPATH points to the ROOTDIR passed as argument, and this ROOTDIR is the global host directory. Rewriting the RPATH to not point to per-package host directories prior to this is an easy solution to this issue. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-05 17:46:40 +01:00
local perpackagedir="${3}"
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
local rpath dir
while read rpath; do
for dir in ${rpath//:/ }; do
# Remove duplicate and trailing '/' for proper match
dir="$( sed -r -e 's:/+:/:g; s:/$::;' <<<"${dir}" )"
[ "${dir}" = "${hostdir}/lib" ] && return 0
[ "${dir}" = "\$ORIGIN/../lib" ] && return 0
# This check is done even for builds where
# BR2_PER_PACKAGE_DIRECTORIES is disabled. In this case,
# PER_PACKAGE_DIR and therefore ${perpackagedir} points to
# a non-existent directory, and this check will always be
# false.
[[ ${dir} =~ "${perpackagedir}/"[^/]+/host/lib ]] && return 0
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
done
support/scripts/check-host-rpath: send readelf error output to oblivion Somewhere between binutils 2.35 and 2.37, some functionality was added in readelf to parse more DWARF information. Unfortunately, as reported in binutils bug 28981 ("https://sourceware.org/bugzilla/show_bug.cgi?id=28981"), this feature causes a number of fairly scary warnings to be displayed when running readelf on binaries built with Clang, such as the pre-built rustc and rustdoc binaries part of the host-rust-bin package. It looks like this: readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 2f in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 10b in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Bogus end-of-siblings marker detected at offset 10c in .debug_info section readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Further warnings about bogus end-of-sibling markers suppressed readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x23 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: Unrecognized form: 0x22 readelf: /home/thomas/projets/buildroot/output/host/bin/rustc: Warning: DIE at offset 0x1da refers to abbreviation number 5827 which does not exist These warnings are caused by the readelf calls done by the support/scripts/check-host-rpath script. The annoying thing is that once host-rust-bin has been installed in $(HOST_DIR), this warning appears after the installation of every single host package, because support/scripts/check-host-rpath rescans all binaries every time. To avoid showing those scary warnings, this commit sends the error output of readelf to /dev/null. Of course, it would be nicer to only filter out those warnings, but filtering the error output without merging the error output into the standard output is tricky, so let's keep things simple. If there is really an error, readelf will abort. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-07-27 12:47:51 +02:00
done < <( readelf -d "${file}" 2>/dev/null \
core: check host executables have appropriate RPATH When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-13 22:48:51 +01:00
|sed -r -e '/.* \(R(UN)?PATH\) +Library r(un)?path: \[(.+)\]$/!d' \
-e 's//\3/;' \
)
return 1
}
main "${@}"