kumquat-buildroot/toolchain/helpers.mk

557 lines
21 KiB
Makefile
Raw Normal View History

# This Makefile fragment declares toolchain related helper functions.
# The copy_toolchain_lib_root function copies a toolchain library and
# its symbolic links from the sysroot directory to the target
# directory. Note that this function is used both by the external
# toolchain logic, and the glibc package, so care must be taken when
# changing this function.
#
# $1: library name pattern (can include glob wildcards)
#
copy_toolchain_lib_root = \
LIBPATTERN="$(strip $1)"; \
LIBPATHS=`find $(STAGING_DIR)/ -name "$${LIBPATTERN}" 2>/dev/null` ; \
for LIBPATH in $${LIBPATHS} ; do \
while true ; do \
LIBNAME=`basename $${LIBPATH}`; \
2017-07-02 13:39:35 +02:00
DESTDIR=`echo $${LIBPATH} | sed "s,^$(STAGING_DIR)/,," | xargs dirname` ; \
mkdir -p $(TARGET_DIR)/$${DESTDIR}; \
rm -fr $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
if test -h $${LIBPATH} ; then \
cp -d $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
OLD_LIBPATH="$${LIBPATH}"; \
LIBPATH="`readlink -f $${LIBPATH}`"; \
if [ "$${LIBPATH}" = "" ]; then \
echo "LIBPATH empty after trying to resolve symlink $${OLD_LIBPATH}" 1>&2; \
exit 1; \
fi; \
elif test -f $${LIBPATH}; then \
$(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
break ; \
else \
exit -1; \
fi; \
done; \
done
#
# Copy the full external toolchain sysroot directory to the staging
# dir. The operation of this function is rendered a little bit
# complicated by the support for multilib toolchains.
#
# We start by copying etc, 'lib', sbin, usr and usr/'lib' from the
# sysroot of the selected architecture variant (as pointed to by
# ARCH_SYSROOT_DIR). This allows to import into the staging directory
# the C library and companion libraries for the correct architecture
# variant. 'lib' may not be literally 'lib' but could be something else,
# e.g. lib32-fp (as determined by ARCH_LIB_DIR) and we only want to copy
# that lib directory and no other. When copying usr, we therefore need
# to be extra careful not to include usr/lib* but we _do_ want to
# include usr/libexec.
# We are selective in the directories we copy since other directories
# might exist for other architecture variants (on Codesourcery
# toolchain, the sysroot for the default architecture variant contains
# the armv4t and thumb2 subdirectories, which are the sysroot for the
# corresponding architecture variants), and we don't want to import
# them.
#
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
# If ARCH_LIB_DIR is not a singular directory component, e.g.
# 'lib32/octeon2', then symbolic links in ARCH_LIB_DIR and
# usr/ARCH_LIB_DIR may be broken because Buildroot will flatten the
# directory structure (e.g. lib32/octeon2/foo is actually stored in
# lib/foo). This is only relevant for links that contain one or more ../
# components, as links to the current directory are always fine.
# We need to fix the broken links by removing the right amount of ../
# dots from the link destination.
# Once the link destination is valid again, it can be simplified to
# remove the dependency on intermediate directory symlinks.
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
#
toolchain-external: handle ld.so fixups centrally Normally, the Buildroot toolchain logic copies all required libraries from the external toolchain to the staging directory, including the dynamic loader ld-*.so. There are cases, however, where the dynamic loader is _not_ automatically copied to staging. This happens when the dynamic loader is not inside ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of course, that ARCH_LIB_DIR != 'lib'). Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a missing symlink or copying over a missing file. Such toolchain specific fixups are not very nice. Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some toolchains, causing them to have the same problem of a missing dynamic loader. This used to be the case for older Linaro toolchains with libraries in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned patch changes it to 'lib/<tuple>' instead. As a result, the files directly under 'lib/' will no longer be copied. There should be none, but the dynamic loader is a notable exception. [Note: support for these older Linaro toolchain has been removed in 2016.11] Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain into staging, in the central copy_toolchain_sysroot function. The existing toolchain logic will then handle the copy of these files from staging to target. This means the toolchain-specific fixups can be removed. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:41 +01:00
# It is possible that ARCH_LIB_DIR does not contain the dynamic loader
# (ld*.so or similar) because it (or the main symlink to it) normally
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
# resides in /lib while ARCH_LIB_DIR may be something else (e.g. lib64,
# lib/<tuple>, ...). Therefore, copy the dynamic loader separately.
toolchain-external: handle ld.so fixups centrally Normally, the Buildroot toolchain logic copies all required libraries from the external toolchain to the staging directory, including the dynamic loader ld-*.so. There are cases, however, where the dynamic loader is _not_ automatically copied to staging. This happens when the dynamic loader is not inside ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of course, that ARCH_LIB_DIR != 'lib'). Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a missing symlink or copying over a missing file. Such toolchain specific fixups are not very nice. Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some toolchains, causing them to have the same problem of a missing dynamic loader. This used to be the case for older Linaro toolchains with libraries in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned patch changes it to 'lib/<tuple>' instead. As a result, the files directly under 'lib/' will no longer be copied. There should be none, but the dynamic loader is a notable exception. [Note: support for these older Linaro toolchain has been removed in 2016.11] Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain into staging, in the central copy_toolchain_sysroot function. The existing toolchain logic will then handle the copy of these files from staging to target. This means the toolchain-specific fixups can be removed. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:41 +01:00
#
# Then, if the selected architecture variant is not the default one
# (i.e, if SYSROOT_DIR != ARCH_SYSROOT_DIR), then we :
#
# * Import the header files from the default architecture
# variant. Header files are typically shared between the sysroots
# for the different architecture variants. If we use the
# non-default one, header files were not copied by the previous
# step, so we copy them here from the sysroot of the default
# architecture variant.
#
# * Create a symbolic link that matches the name of the subdirectory
# for the architecture variant in the original sysroot. This is
# required as the compiler will by default look in
# sysroot_dir/arch_variant/ for libraries and headers, when the
# non-default architecture variant is used. Without this, the
# compiler fails to find libraries and headers.
#
# Some toolchains (i.e Linaro binary toolchains) store support
# libraries (libstdc++, libgcc_s) outside of the sysroot, so we simply
# copy all the libraries from the "support lib directory" into our
# sysroot.
#
# Note that the 'locale' directories are not copied. They are huge
# (400+MB) in CodeSourcery toolchains, and they are not really useful.
#
# $1: main sysroot directory of the toolchain
# $2: arch specific sysroot directory of the toolchain
# $3: arch specific subdirectory in the sysroot
toolchain-external: fix lib64 symlinks * Always link lib64 or lib32 to lib * Only copy the architecture's lib directory to staging * Also cleanup a couple of mkdirs (concerning some 'lib' directories). Before this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Aug 12 22:26 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ drwxr-xr-x 5 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/lib': Too many levels of symbolic links find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/lib': Too many levels of symbolic links ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_files.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nis.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_compat.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nisplus.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libutil.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libthread_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcidn.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_hesiod.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnsl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/librt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libanl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libBrokenLocale.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_dns.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libresolv.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so ./target/etc/resolv.conf ./target/dev/log After this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64 -> lib/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64 -> lib/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks ./target/etc/resolv.conf ./target/dev/log Fixes http://autobuild.buildroot.net/results/23fb6b1479d2b5906b72c9437b06ab4700ff246d/ Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-08-23 00:59:35 +02:00
# $4: directory of libraries ('lib', 'lib32' or 'lib64')
# $5: support lib directories (for toolchains storing libgcc_s,
# libstdc++ and other gcc support libraries outside of the
# sysroot)
copy_toolchain_sysroot = \
SYSROOT_DIR="$(strip $1)"; \
ARCH_SYSROOT_DIR="$(strip $2)"; \
ARCH_SUBDIR="$(strip $3)"; \
Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2011-12-31 11:57:15 +01:00
ARCH_LIB_DIR="$(strip $4)" ; \
SUPPORT_LIB_DIR="$(strip $5)" ; \
toolchain-external: fix lib64 symlinks * Always link lib64 or lib32 to lib * Only copy the architecture's lib directory to staging * Also cleanup a couple of mkdirs (concerning some 'lib' directories). Before this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Aug 12 22:26 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ drwxr-xr-x 5 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/lib': Too many levels of symbolic links find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/lib': Too many levels of symbolic links ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_files.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nis.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_compat.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nisplus.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libutil.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libthread_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcidn.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_hesiod.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnsl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/librt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libanl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libBrokenLocale.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_dns.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libresolv.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so ./target/etc/resolv.conf ./target/dev/log After this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64 -> lib/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64 -> lib/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks ./target/etc/resolv.conf ./target/dev/log Fixes http://autobuild.buildroot.net/results/23fb6b1479d2b5906b72c9437b06ab4700ff246d/ Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-08-23 00:59:35 +02:00
for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
if [ ! -d $${ARCH_SYSROOT_DIR}/$$i ] ; then \
continue ; \
fi ; \
if [ "$$i" = "usr" ]; then \
rsync -au --chmod=u=rwX,go=rX --exclude 'locale/' \
--include '/libexec*/' --exclude '/lib*/' \
$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
else \
rsync -au --chmod=u=rwX,go=rX --exclude 'locale/' \
$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
fi ; \
done ; \
toolchain: replace absolute symlinks by relative symlinks during sysroot copy In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") we changed how the musl dynamic linker symbolic link was being created. Instead of having specific logic in Buildroot, we switched to simply copying the ld*.so.* symbolic link from staging to target, as well as the target of this symbolic link. However, it turns out that by default, musl creates its dynamic linker symbolic link with an absolute path as the target of the link: /lib/libc.so. Therefore, external Musl toolchains built with Buildroot look like this: lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so The principle of the copy_toolchain_lib_root function, which is used to copy libraries from staging to target, is to copy symbolic links and follow their targets. In this case, it means we end up copying /lib/libc.so (from the host machine) into the target folder. From there on, there are two cases: 1. /lib/libc.so exists in your host system. It gets copied to the target. But later on, Buildroot also copies /lib/libc.so from staging to target, overwriting the bogus libc.so. So everything works fine, even though it's admittedly ugly. 2. /lib/libc.so doesn't exist in your host system. In this case, the build fails with no clear error message. This problem does not happen with Musl toolchains built by Crosstool-NG, because Crosstool-NG replaces the absolute target of the dynamic linker symbolic link by a relative path. However, since we want to support existing Buildroot Musl toolchains and generally work with the fact that Musl by default installs an absolute symlink, the following commit improves the copy_toolchain_sysroot function to replace symbolic links with an absolute destination to use a relative destination. I.e, in staging, the ld-musl-armhf.so.1 symbolic link looks like this: lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so Fixes: http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05 23:08:03 +02:00
for link in $$(find $(STAGING_DIR) -type l); do \
target=$$(readlink $${link}) ; \
if [ "$${target}" == "$${target$(SHARP_SIGN)/}" ] ; then \
toolchain: replace absolute symlinks by relative symlinks during sysroot copy In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") we changed how the musl dynamic linker symbolic link was being created. Instead of having specific logic in Buildroot, we switched to simply copying the ld*.so.* symbolic link from staging to target, as well as the target of this symbolic link. However, it turns out that by default, musl creates its dynamic linker symbolic link with an absolute path as the target of the link: /lib/libc.so. Therefore, external Musl toolchains built with Buildroot look like this: lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so The principle of the copy_toolchain_lib_root function, which is used to copy libraries from staging to target, is to copy symbolic links and follow their targets. In this case, it means we end up copying /lib/libc.so (from the host machine) into the target folder. From there on, there are two cases: 1. /lib/libc.so exists in your host system. It gets copied to the target. But later on, Buildroot also copies /lib/libc.so from staging to target, overwriting the bogus libc.so. So everything works fine, even though it's admittedly ugly. 2. /lib/libc.so doesn't exist in your host system. In this case, the build fails with no clear error message. This problem does not happen with Musl toolchains built by Crosstool-NG, because Crosstool-NG replaces the absolute target of the dynamic linker symbolic link by a relative path. However, since we want to support existing Buildroot Musl toolchains and generally work with the fact that Musl by default installs an absolute symlink, the following commit improves the copy_toolchain_sysroot function to replace symbolic links with an absolute destination to use a relative destination. I.e, in staging, the ld-musl-armhf.so.1 symbolic link looks like this: lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so Fixes: http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05 23:08:03 +02:00
continue ; \
fi ; \
relpath="$(call relpath_prefix,$${target$(SHARP_SIGN)/})" ; \
echo "Fixing symlink $${link} from $${target} to $${relpath}$${target$(SHARP_SIGN)/}" ; \
ln -sf $${relpath}$${target$(SHARP_SIGN)/} $${link} ; \
toolchain: replace absolute symlinks by relative symlinks during sysroot copy In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") we changed how the musl dynamic linker symbolic link was being created. Instead of having specific logic in Buildroot, we switched to simply copying the ld*.so.* symbolic link from staging to target, as well as the target of this symbolic link. However, it turns out that by default, musl creates its dynamic linker symbolic link with an absolute path as the target of the link: /lib/libc.so. Therefore, external Musl toolchains built with Buildroot look like this: lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so The principle of the copy_toolchain_lib_root function, which is used to copy libraries from staging to target, is to copy symbolic links and follow their targets. In this case, it means we end up copying /lib/libc.so (from the host machine) into the target folder. From there on, there are two cases: 1. /lib/libc.so exists in your host system. It gets copied to the target. But later on, Buildroot also copies /lib/libc.so from staging to target, overwriting the bogus libc.so. So everything works fine, even though it's admittedly ugly. 2. /lib/libc.so doesn't exist in your host system. In this case, the build fails with no clear error message. This problem does not happen with Musl toolchains built by Crosstool-NG, because Crosstool-NG replaces the absolute target of the dynamic linker symbolic link by a relative path. However, since we want to support existing Buildroot Musl toolchains and generally work with the fact that Musl by default installs an absolute symlink, the following commit improves the copy_toolchain_sysroot function to replace symbolic links with an absolute destination to use a relative destination. I.e, in staging, the ld-musl-armhf.so.1 symbolic link looks like this: lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so Fixes: http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-05 23:08:03 +02:00
done ; \
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
relpath="$(call relpath_prefix,$${ARCH_LIB_DIR})" ; \
if [ "$${relpath}" != "" ]; then \
for i in $$(find -H $(STAGING_DIR)/$${ARCH_LIB_DIR} $(STAGING_DIR)/usr/$${ARCH_LIB_DIR} -type l -xtype l); do \
LINKTARGET=`readlink $$i` ; \
NEWLINKTARGET=$${LINKTARGET\#$$relpath} ; \
ln -sf $${NEWLINKTARGET} $$i ; \
$(call simplify_symlink,$$i,$(STAGING_DIR)) ; \
toolchain-external: cover multilib toolchains with lib/<variant> layout The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:43 +01:00
done ; \
fi ; \
if [[ ! $$(find $(STAGING_DIR)/lib -name 'ld*.so.*' -print -quit) ]]; then \
find $${ARCH_SYSROOT_DIR}/lib -name 'ld*.so.*' -print0 | xargs -0 -I % cp % $(STAGING_DIR)/lib/; \
toolchain-external: handle ld.so fixups centrally Normally, the Buildroot toolchain logic copies all required libraries from the external toolchain to the staging directory, including the dynamic loader ld-*.so. There are cases, however, where the dynamic loader is _not_ automatically copied to staging. This happens when the dynamic loader is not inside ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of course, that ARCH_LIB_DIR != 'lib'). Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a missing symlink or copying over a missing file. Such toolchain specific fixups are not very nice. Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some toolchains, causing them to have the same problem of a missing dynamic loader. This used to be the case for older Linaro toolchains with libraries in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned patch changes it to 'lib/<tuple>' instead. As a result, the files directly under 'lib/' will no longer be copied. There should be none, but the dynamic loader is a notable exception. [Note: support for these older Linaro toolchain has been removed in 2016.11] Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain into staging, in the central copy_toolchain_sysroot function. The existing toolchain logic will then handle the copy of these files from staging to target. This means the toolchain-specific fixups can be removed. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-02-07 22:56:41 +01:00
fi ; \
if [ `readlink -f $${SYSROOT_DIR}` != `readlink -f $${ARCH_SYSROOT_DIR}` ] ; then \
if [ ! -d $${ARCH_SYSROOT_DIR}/usr/include ] ; then \
cp -a $${SYSROOT_DIR}/usr/include $(STAGING_DIR)/usr ; \
fi ; \
mkdir -p `dirname $(STAGING_DIR)/$${ARCH_SUBDIR}` ; \
relpath="$(call relpath_prefix,$${ARCH_SUBDIR})./" ; \
ln -s $${relpath} $(STAGING_DIR)/$${ARCH_SUBDIR} ; \
echo "Symlinking $(STAGING_DIR)/$${ARCH_SUBDIR} -> $${relpath}" ; \
fi ; \
if test -n "$${SUPPORT_LIB_DIR}" ; then \
cp -a $${SUPPORT_LIB_DIR}/* $(STAGING_DIR)/lib/ ; \
fi ; \
find $(STAGING_DIR) -type d -print0 | xargs -0 chmod 755
#
# Check the specified kernel headers version actually matches the
# version in the toolchain.
#
# $1: build directory
# $2: sysroot directory
# $3: kernel version string, in the form: X.Y
# $4: test to do for the latest kernel version, 'strict' or 'loose'
# always 'strict' if this is not the latest version.
#
check_kernel_headers_version = \
if ! support/scripts/check-kernel-headers.sh $(1) $(2) $(3) \
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
then \
exit 1; \
fi
#
# Check the specific gcc version actually matches the version in the
# toolchain
#
# $1: path to gcc
# $2: expected gcc version
#
check_gcc_version = \
expected_version="$(strip $2)" ; \
if [ -z "$${expected_version}" ]; then \
exit 0 ; \
fi; \
real_version=`$(1) -dumpversion` ; \
if [[ ! "$${real_version}." =~ ^$${expected_version}\. ]] ; then \
printf "Incorrect selection of gcc version: expected %s.x, got %s\n" \
"$${expected_version}" "$${real_version}" ; \
exit 1 ; \
fi
#
# Check the availability of a particular glibc feature. This function
# is used to check toolchain options that are always supported by
# glibc, so we simply check that the corresponding option is properly
# enabled.
#
# $1: Buildroot option name
# $2: feature description
#
check_glibc_feature = \
if [ "$($(1))" != "y" ] ; then \
echo "$(2) available in C library, please enable $(1)" ; \
exit 1 ; \
fi
#
# Check the availability of RPC support in a glibc toolchain
#
# $1: sysroot directory
#
check_glibc_rpc_feature = \
IS_IN_LIBC=`test -f $(1)/usr/include/rpc/rpc.h && echo y` ; \
if [ "$(BR2_TOOLCHAIN_HAS_NATIVE_RPC)" != "y" -a "$${IS_IN_LIBC}" = "y" ] ; then \
echo "RPC support available in C library, please enable BR2_TOOLCHAIN_EXTERNAL_INET_RPC" ; \
exit 1 ; \
fi ; \
if [ "$(BR2_TOOLCHAIN_HAS_NATIVE_RPC)" = "y" -a "$${IS_IN_LIBC}" != "y" ] ; then \
echo "RPC support not available in C library, please disable BR2_TOOLCHAIN_EXTERNAL_INET_RPC" ; \
exit 1 ; \
fi
#
# Check the correctness of a glibc external toolchain configuration.
# 1. Check that the C library selected in Buildroot matches the one
# of the external toolchain
# 2. Check that all the C library-related features are enabled in the
# config, since glibc always supports all of them
#
# $1: sysroot directory
#
check_glibc = \
SYSROOT_DIR="$(strip $1)"; \
if test `find -L $${SYSROOT_DIR}/ -maxdepth 2 -name 'ld-linux*.so.*' -o -name 'ld.so.*' -o -name 'ld64.so.*' | wc -l` -eq 0 ; then \
echo "Incorrect selection of the C library"; \
exit -1; \
fi; \
$(call check_glibc_feature,BR2_USE_MMU,MMU support) ;\
$(call check_glibc_rpc_feature,$${SYSROOT_DIR})
#
# Check that the selected C library really is musl
#
# $1: cross-gcc path
# $2: cross-readelf path
check_musl = \
__CROSS_CC=$(strip $1) ; \
libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
echo "Incorrect selection of the C library" ; \
exit -1; \
fi
#
# Check the conformity of Buildroot configuration with regard to the
# uClibc configuration of the external toolchain, for a particular
# feature.
#
# If 'Buildroot option name' ($2) is empty it means the uClibc option
# is mandatory.
#
# $1: uClibc macro name
# $2: Buildroot option name
# $3: uClibc config file
# $4: feature description
#
check_uclibc_feature = \
IS_IN_LIBC=`grep -q "\#define $(1) 1" $(3) && echo y` ; \
if [ -z "$(2)" ] ; then \
if [ "$${IS_IN_LIBC}" != "y" ] ; then \
echo "$(4) not available in C library, toolchain unsuitable for Buildroot" ; \
exit 1 ; \
fi ; \
else \
if [ "$($(2))" != "y" -a "$${IS_IN_LIBC}" = "y" ] ; then \
echo "$(4) available in C library, please enable $(2)" ; \
exit 1 ; \
fi ; \
if [ "$($(2))" = "y" -a "$${IS_IN_LIBC}" != "y" ] ; then \
echo "$(4) not available in C library, please disable $(2)" ; \
exit 1 ; \
fi ; \
fi
#
# Check the correctness of a uclibc external toolchain configuration
# 1. Check that the C library selected in Buildroot matches the one
# of the external toolchain
# 2. Check that the features enabled in the Buildroot configuration
# match the features available in the uClibc of the external
# toolchain
#
# $1: sysroot directory
#
check_uclibc = \
SYSROOT_DIR="$(strip $1)"; \
if ! test -f $${SYSROOT_DIR}/usr/include/bits/uClibc_config.h ; then \
echo "Incorrect selection of the C library"; \
exit -1; \
fi; \
UCLIBC_CONFIG_FILE=$${SYSROOT_DIR}/usr/include/bits/uClibc_config.h ; \
$(call check_uclibc_feature,__ARCH_USE_MMU__,BR2_USE_MMU,$${UCLIBC_CONFIG_FILE},MMU support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_LFS__,,$${UCLIBC_CONFIG_FILE},Large file support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_IPV6__,,$${UCLIBC_CONFIG_FILE},IPv6 support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_RPC__,BR2_TOOLCHAIN_HAS_NATIVE_RPC,$${UCLIBC_CONFIG_FILE},RPC support) ;\
toolchain/helpers.mk: strengthen uClibc locale check Currently, when verifying the configuration of a uClibc toolchain for the presence of locale support, we check __UCLIBC_HAS_LOCALE__. It turns out that we in fact also expect __UCLIBC_HAS_XLOCALE__ to be defined, as without it locale_t is not defined, causing build failure in some packages, such as libcpprestsdk: In file included from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/json.h:18, from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/pch/stdafx.h:88, from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/http/client/http_client_msg.cpp:13: /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/asyncrt_utils.h:317:13: error: 'locale_t' does not name a type 317 | typedef locale_t xplat_locale; | ^~~~~~~~ As essentially our requirement for uClibc in external toolchains is "it should match the uClibc configuration used by Buildroot for internal toolchains", it makes sense to verify __UCLIBC_HAS_XLOCALE__. Note that of course checking __UCLIBC_HAS_XLOCALE__ is sufficient, as it cannot be enabled if __UCLIBC_HAS_LOCALE isn't. This addresses an issue with the Synopsys ARC external toolchain, which is built with __UCLIBC_HAS_LOCALE__, but without __UCLIBC_HAS_XLOCALE__ causing a build failure with some packages (such as libcpprestsdk). Therefore, this patch also changes how the Synospys ARC external toolchain is exposed in Buildroot: it no longer advertise locale support. Fixes: http://autobuild.buildroot.org/results/e6778e60cc1ea455f5b4511d5824f04d8040f67b Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2023-02-21 15:35:33 +01:00
$(call check_uclibc_feature,__UCLIBC_HAS_XLOCALE__,BR2_ENABLE_LOCALE,$${UCLIBC_CONFIG_FILE},Locale support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_WCHAR__,BR2_USE_WCHAR,$${UCLIBC_CONFIG_FILE},Wide char support) ;\
2011-11-24 14:26:52 +01:00
$(call check_uclibc_feature,__UCLIBC_HAS_THREADS__,BR2_TOOLCHAIN_HAS_THREADS,$${UCLIBC_CONFIG_FILE},Thread support) ;\
$(call check_uclibc_feature,__PTHREADS_DEBUG_SUPPORT__,BR2_TOOLCHAIN_HAS_THREADS_DEBUG,$${UCLIBC_CONFIG_FILE},Thread debugging support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_THREADS_NATIVE__,BR2_TOOLCHAIN_HAS_THREADS_NPTL,$${UCLIBC_CONFIG_FILE},NPTL thread support)
#
# Check that the Buildroot configuration of the ABI matches the
# configuration of the external toolchain.
#
# $1: cross-gcc path
# $2: cross-readelf path
#
check_arm_abi = \
__CROSS_CC=$(strip $1) ; \
EXT_TOOLCHAIN_TARGET=`LANG=C $${__CROSS_CC} -v 2>&1 | grep ^Target | cut -f2 -d ' '` ; \
if ! echo $${EXT_TOOLCHAIN_TARGET} | grep -qE 'eabi(hf)?$$' ; then \
echo "External toolchain uses the unsuported OABI" ; \
exit 1 ; \
fi ; \
if ! echo 'int main(void) {}' | $${__CROSS_CC} -x c -o $(BUILD_DIR)/.br-toolchain-test.tmp - ; then \
rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*; \
abistr_$(BR2_ARM_EABI)='EABI'; \
abistr_$(BR2_ARM_EABIHF)='EABIhf'; \
echo "Incorrect ABI setting: $${abistr_y} selected, but toolchain is incompatible"; \
exit 1 ; \
fi ; \
rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
#
# Check that the external toolchain supports C++
#
# $1: cross-g++ path
#
check_cplusplus = \
__CROSS_CXX=$(strip $1) ; \
__HAS_CXX=`$${__CROSS_CXX} -v > /dev/null 2>&1 && echo y`; \
if [ "$${__HAS_CXX}" != "y" -a "$(BR2_INSTALL_LIBSTDCPP)" = y ] ; then \
echo "C++ support is selected but is not available in external toolchain" ; \
exit 1 ; \
elif [ "$${__HAS_CXX}" = "y" -a "$(BR2_INSTALL_LIBSTDCPP)" != y ] ; then \
echo "C++ support is not selected but is available in external toolchain" ; \
exit 1 ; \
fi \
#
#
# Check that the external toolchain supports D language
#
# $1: cross-gdc path
#
check_dlang = \
__CROSS_GDC=$(strip $1) ; \
__o=$(BUILD_DIR)/.br-toolchain-test-dlang.tmp ; \
__HAS_DLANG=`printf 'import std.stdio;\nvoid main() { writeln("Hello World!"); }\n' | \
$${__CROSS_GDC} -x d -o $${__o} - >/dev/null 2>&1 && echo y`; \
rm -f $${__o}* ; \
if [ "$${__HAS_DLANG}" != "y" -a "$(BR2_TOOLCHAIN_HAS_DLANG)" = y ] ; then \
echo "D language support is selected but is not available in external toolchain" ; \
exit 1 ; \
elif [ "$${__HAS_DLANG}" = "y" -a "$(BR2_TOOLCHAIN_HAS_DLANG)" != y ] ; then \
echo "D language support is not selected but is available in external toolchain" ; \
exit 1 ; \
fi \
#
#
# Check that the external toolchain supports Fortran
#
# $1: cross-gfortran path
#
check_fortran = \
__CROSS_FC=$(strip $1) ; \
__o=$(BUILD_DIR)/.br-toolchain-test-fortran.tmp ; \
__HAS_FORTRAN=`printf 'program hello\n\tprint *, "Hello Fortran!\\\n"\nend program hello\n' | \
$${__CROSS_FC} -x f95 -ffree-form -o $${__o} - 2>/dev/null && echo y`; \
rm -f $${__o}* ; \
if [ "$${__HAS_FORTRAN}" != "y" -a "$(BR2_TOOLCHAIN_HAS_FORTRAN)" = y ] ; then \
echo "Fortran support is selected but is not available in external toolchain" ; \
exit 1 ; \
elif [ "$${__HAS_FORTRAN}" = "y" -a "$(BR2_TOOLCHAIN_HAS_FORTRAN)" != y ] ; then \
echo "Fortran support is not selected but is available in external toolchain" ; \
exit 1 ; \
fi \
#
#
# Check that the external toolchain supports OpenMP
#
# $1: cross-gcc path
#
check_openmp = \
__CROSS_CC=$(strip $1) ; \
__o=$(BUILD_DIR)/.br-toolchain-test-openmp.tmp ; \
__HAS_OPENMP=`printf '\#include <omp.h>\nint main(void) { return omp_get_thread_num(); }' | \
$${__CROSS_CC} -fopenmp -x c -o $${__o} - >/dev/null 2>&1 && echo y` ; \
rm -f $${__o}* ; \
if [ "$${__HAS_OPENMP}" != "y" -a "$(BR2_TOOLCHAIN_HAS_OPENMP)" = y ] ; then \
echo "OpenMP support is selected but is not available in external toolchain"; \
exit 1 ; \
elif [ "$${__HAS_OPENMP}" = "y" -a "$(BR2_TOOLCHAIN_HAS_OPENMP)" != y ] ; then \
echo "OpenMP support is not selected but is available in external toolchain"; \
exit 1 ; \
fi \
#
# Check that the cross-compiler given in the configuration exists
#
# $1: cross-gcc path
#
check_cross_compiler_exists = \
__CROSS_CC=$(strip $1) ; \
$${__CROSS_CC} -v > /dev/null 2>&1 ; \
if test $$? -ne 0 ; then \
echo "Cannot execute cross-compiler '$${__CROSS_CC}'" ; \
exit 1 ; \
fi
#
# Check for toolchains known not to work with Buildroot.
# - For the Angstrom toolchains, we check by looking at the vendor part of
# the host tuple.
# - Exclude distro-class toolchains which are not relocatable.
# - Exclude broken toolchains which return "libc.a" with -print-file-name.
toolchain/helper: check the arch sysroot Since the commit [1], the utils/genrandconfig script improved the configuration randomization used by autobuilders. Since then it can generate a configuration that is not suitable for an external toolchain such the "Codescape IMG GNU Linux Toolchain". Indeed this toolchain can be selected for mips32r5 or mips64r5 while only mips32r2 or mips64r2 are really supported. The toolchain issue will be fixed in a followup change. We want to catch such issue in check_unusable_toolchain function otherwise it is detected late during the sysroot import into staging and trigger a weird error message: ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot/usr//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory This is similar test than for the main sysroot check but this time we have to use the toolchain cflags to check the architecture sysroot. If the architecture sysroot doesn't exist, the toolchain will reply with "libc.a". Either the toolchain is really broken or we used a wrong target architecture variant. In the later case, the toolchain infrastructure will print a meaningful error message. Note: We also may get a similar issue using the toolchain-external-custom package if a toolchain is used with a wrong target architecture variant. Fixes: http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/ [1] aeee90ec109b83c42779e6a2617f7d57e25a2b65 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2023-02-11 19:28:38 +01:00
# - Exclude toolchains used with wrong toolchain cflags or broken toolchains
# which return "libc.a" with -print-file-name and toolchain cflags.
# - Exclude toolchains which doesn't support --sysroot option.
#
# $1: cross-gcc path
toolchain/helper: check the arch sysroot Since the commit [1], the utils/genrandconfig script improved the configuration randomization used by autobuilders. Since then it can generate a configuration that is not suitable for an external toolchain such the "Codescape IMG GNU Linux Toolchain". Indeed this toolchain can be selected for mips32r5 or mips64r5 while only mips32r2 or mips64r2 are really supported. The toolchain issue will be fixed in a followup change. We want to catch such issue in check_unusable_toolchain function otherwise it is detected late during the sysroot import into staging and trigger a weird error message: ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot/usr//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory This is similar test than for the main sysroot check but this time we have to use the toolchain cflags to check the architecture sysroot. If the architecture sysroot doesn't exist, the toolchain will reply with "libc.a". Either the toolchain is really broken or we used a wrong target architecture variant. In the later case, the toolchain infrastructure will print a meaningful error message. Note: We also may get a similar issue using the toolchain-external-custom package if a toolchain is used with a wrong target architecture variant. Fixes: http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/ [1] aeee90ec109b83c42779e6a2617f7d57e25a2b65 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2023-02-11 19:28:38 +01:00
# $1: toolchain cflags
#
check_unusable_toolchain = \
__CROSS_CC=$(strip $1) ; \
toolchain/helper: check the arch sysroot Since the commit [1], the utils/genrandconfig script improved the configuration randomization used by autobuilders. Since then it can generate a configuration that is not suitable for an external toolchain such the "Codescape IMG GNU Linux Toolchain". Indeed this toolchain can be selected for mips32r5 or mips64r5 while only mips32r2 or mips64r2 are really supported. The toolchain issue will be fixed in a followup change. We want to catch such issue in check_unusable_toolchain function otherwise it is detected late during the sysroot import into staging and trigger a weird error message: ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot/usr//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory This is similar test than for the main sysroot check but this time we have to use the toolchain cflags to check the architecture sysroot. If the architecture sysroot doesn't exist, the toolchain will reply with "libc.a". Either the toolchain is really broken or we used a wrong target architecture variant. In the later case, the toolchain infrastructure will print a meaningful error message. Note: We also may get a similar issue using the toolchain-external-custom package if a toolchain is used with a wrong target architecture variant. Fixes: http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/ [1] aeee90ec109b83c42779e6a2617f7d57e25a2b65 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2023-02-11 19:28:38 +01:00
__TOOLCHAIN_CFLAGS=$(strip $2) ; \
vendor=`$${__CROSS_CC} -dumpmachine | cut -f2 -d'-'` ; \
if test "$${vendor}" = "angstrom" ; then \
echo "Angstrom toolchains are not pure toolchains: they contain" ; \
echo "many other libraries than just the C library, which makes" ; \
echo "them unsuitable as external toolchains for build systems" ; \
echo "such as Buildroot." ; \
exit 1 ; \
fi; \
with_sysroot=`$${__CROSS_CC} -v 2>&1 |sed -r -e '/.* --with-sysroot=([^[:space:]]+)[[:space:]].*/!d; s//\1/'`; \
if test "$${with_sysroot}" = "/" ; then \
echo "Distribution toolchains are unsuitable for use by Buildroot," ; \
echo "as they were configured in a way that makes them non-relocatable,"; \
echo "and contain a lot of pre-built libraries that would conflict with"; \
echo "the ones Buildroot wants to build."; \
exit 1; \
fi; \
libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
if test "$${libc_a_path}" = "libc.a" ; then \
echo "Unable to detect the toolchain sysroot, Buildroot cannot use this toolchain." ; \
exit 1 ; \
fi ; \
toolchain/helper: check the arch sysroot Since the commit [1], the utils/genrandconfig script improved the configuration randomization used by autobuilders. Since then it can generate a configuration that is not suitable for an external toolchain such the "Codescape IMG GNU Linux Toolchain". Indeed this toolchain can be selected for mips32r5 or mips64r5 while only mips32r2 or mips64r2 are really supported. The toolchain issue will be fixed in a followup change. We want to catch such issue in check_unusable_toolchain function otherwise it is detected late during the sysroot import into staging and trigger a weird error message: ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot/usr//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory This is similar test than for the main sysroot check but this time we have to use the toolchain cflags to check the architecture sysroot. If the architecture sysroot doesn't exist, the toolchain will reply with "libc.a". Either the toolchain is really broken or we used a wrong target architecture variant. In the later case, the toolchain infrastructure will print a meaningful error message. Note: We also may get a similar issue using the toolchain-external-custom package if a toolchain is used with a wrong target architecture variant. Fixes: http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/ [1] aeee90ec109b83c42779e6a2617f7d57e25a2b65 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2023-02-11 19:28:38 +01:00
libc_a_archsysroot_path=`$${__CROSS_CC} $${__TOOLCHAIN_CFLAGS} -print-file-name=libc.a` ; \
if test "$${libc_a_archsysroot_path}" = "libc.a" ; then \
echo "Unable to detect the toolchain architecture sysroot." ; \
echo "Please check the Target Architecture Variant selected, the toolchains may not support it." ; \
echo "Buildroot cannot use this toolchain." ; \
exit 1 ; \
fi; \
sysroot_dir="$(call toolchain_find_sysroot,$${__CROSS_CC})" ; \
if test -z "$${sysroot_dir}" ; then \
echo "External toolchain doesn't support --sysroot. Cannot use." ; \
exit 1 ; \
fi
#
# Check if the toolchain has SSP (stack smashing protector) support
#
# $1: cross-gcc path
# $2: gcc ssp option
#
check_toolchain_ssp = \
__CROSS_CC=$(strip $1) ; \
__HAS_SSP=`echo 'int main(){}' | $${__CROSS_CC} -Werror -fstack-protector -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 && echo y` ; \
if [ "$(BR2_TOOLCHAIN_HAS_SSP)" != "y" -a "$${__HAS_SSP}" = "y" ] ; then \
echo "SSP support available in this toolchain, please enable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \
exit 1 ; \
fi ; \
if [ "$(BR2_TOOLCHAIN_HAS_SSP)" = "y" -a "$${__HAS_SSP}" != "y" ] ; then \
echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \
exit 1 ; \
fi ; \
__SSP_OPTION=$(2); \
if [ -n "$${__SSP_OPTION}" ] ; then \
if ! echo 'int main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \
echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \
exit 1 ; \
fi; \
fi; \
rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
#
# Generate gdbinit file for use with Buildroot
#
gen_gdbinit_file = \
mkdir -p $(STAGING_DIR)/usr/share/buildroot/ ; \
toolchain/helpers.mk: gdbinit: set auto-load-safe-path before sysroot The gdbinit supplied by Buildroot does two things: A. specify the sysroot where gdb can find shared libraries B. mark the sysroot as a 'safe path' for its auto-load feature, to make sure that pretty printers for libstdc++.so are added automatically (see commit 6fb3216a80c64c08375429d89497eaeec5622150) When debugging a core file, and the gdbinit file is specified via '-x' rather than '-ix', then the order of these settings matters: If you first set the sysroot, then gdb will immediately start finding the shared libraries it needs for the core file, detect libstdc++ and its associated libstdc++-gdb.py file, then give a big warning about safe paths: warning: File ".../i686-buildroot-linux-gnu/sysroot/lib/libstdc++.so.6.0.24-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path .../i686-buildroot-linux-gnu/sysroot/lib/libstdc++.so.6.0.24-gdb.py line to your configuration file "/home/me/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/me/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" and the pretty printing code is not loaded. This is because the second line from the gdbinit file was not yet parsed at this point. By changing the order (first configuring the safe path, then setting the sysroot), this issue does not appear and everything is as expected. Note that when '-ix' were used instead of '-x' to pass the gdbinit file to gdb, then the order would not matter, because the entire gdbinit file would be parsed before considering the core file. However, even though the Buildroot manual now suggests '-ix', users may not have noticed this change and continue to use '-x'. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-09-13 09:29:42 +02:00
echo "add-auto-load-safe-path $(STAGING_DIR)" > $(STAGING_DIR)/usr/share/buildroot/gdbinit ; \
echo "set sysroot $(STAGING_DIR)" >> $(STAGING_DIR)/usr/share/buildroot/gdbinit
# Given a path, determine the relative prefix (../) needed to return to the
# root level. Note that the last component is treated as a file component; use a
# trailing slash to force treating it as a directory. Examples:
# relpath_prefix(lib32) = ""
# relpath_prefix(lib32/octeon2) = "../"
# relpath_prefix(lib32/octeon2/) = "../../"
#
# $1: input path
define relpath_prefix
$$( \
prefix="" ; \
nbslashs=`printf $1 | sed 's%[^/]%%g' | wc -c` ; \
for slash in `seq 1 $${nbslashs}` ; do \
prefix=$${prefix}"../" ; \
done ; \
printf "$$prefix" ; \
)
endef
# Replace the destination of a symbolic link with a simpler version
# For example,
# usr/lib/libfoo.so -> ../../lib32/libfoo.so.1
# becomes
# usr/lib/libfoo.so -> ../../lib/libfoo.so.1
# since 'lib32' is a symlink to 'lib'.
#
# Likewise,
# usr/lib/octeon2/libbar.so -> ../../../lib32/octeon2/libbar.so.1
# becomes
# usr/lib/octeon2/libbar.so -> ../../lib/libbar.so.1
# assuming lib32->lib and lib/octeon2->lib.
#
# $1: symlink
# $2: base path
define simplify_symlink
( \
FULL_SRC="$$(readlink -f $$(dirname $1))/$$(basename $1)" ; \
FULL_DEST="$$(readlink -f $1)" ; \
FULL_BASE="$$(readlink -f $2)" ; \
REL_SRC="$${FULL_SRC#$${FULL_BASE}/}" ; \
REL_DEST="$${FULL_DEST#$${FULL_BASE}/}" ; \
DOTS="$(call relpath_prefix,$${REL_SRC})" ; \
ln -sf "$${DOTS}$${REL_DEST}" "$${FULL_SRC}" ; \
)
endef