2013-10-08 20:17:07 +02:00
|
|
|
# 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.
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
2017-02-07 22:56:48 +01:00
|
|
|
# $1: library name pattern (can include glob wildcards)
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
|
|
|
copy_toolchain_lib_root = \
|
2017-02-07 22:56:48 +01:00
|
|
|
LIBPATTERN="$(strip $1)"; \
|
|
|
|
LIBPATHS=`find $(STAGING_DIR)/ -name "$${LIBPATTERN}" 2>/dev/null` ; \
|
2016-02-03 22:45:28 +01:00
|
|
|
for LIBPATH in $${LIBPATHS} ; do \
|
2013-10-08 20:17:14 +02:00
|
|
|
while true ; do \
|
|
|
|
LIBNAME=`basename $${LIBPATH}`; \
|
toolchain/helpers.mk: re-evaluate DESTDIR in copy_toolchain_lib_root
copy_toolchain_lib_root copies libraries from staging to target,
resolving and copying symbolic links along the way.
The most inner loop, a "while" loop, starts from an initial name, and
if it's a symbolic link, gets resolved to the target, and the loop
iterates until we reach a real file. However, the destination folder
where the symbolic link or real file is created is computed in DESTDIR
only once, before this loop starts. Therefore, this loop works fine
when all symbolic links in the chain, and the real file all belong to
the same directory. But it doesn't do the correct thing when the
symbolic link and/or real file are in different folder.
An example is Crosstool-NG musl toolchains, where the dynamic loader
is in /lib/ld-musl*.so but points to ../usr/lib/libc.so. With the
current logic, we copy /lib/ld-musl*.so to /lib, but we also copy
libc.so to /lib instead of the expected /usr/lib.
This currently doesn't cause any problem because the musl dynamic
linker is manually created by the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
hook. However, this logic has a number of problems, so in a followup
commit, we are going to put the musl dynamic linker in
TOOLCHAIN_EXTERNAL_LIBS, which will cause it to be copied by
copy_toolchain_lib_root. But we obviously want the link and its target
to be copied to the right place, hence this fix.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-02 13:39:35 +02:00
|
|
|
DESTDIR=`echo $${LIBPATH} | sed "s,^$(STAGING_DIR)/,," | xargs dirname` ; \
|
2017-07-05 16:54:18 +02:00
|
|
|
mkdir -p $(TARGET_DIR)/$${DESTDIR}; \
|
2012-05-07 15:02:19 +02:00
|
|
|
rm -fr $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
|
|
|
|
if test -h $${LIBPATH} ; then \
|
2017-02-07 22:56:49 +01:00
|
|
|
cp -d $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
|
2022-06-25 00:19:01 +02:00
|
|
|
OLD_LIBPATH="$${LIBPATH}"; \
|
2017-02-07 22:56:47 +01:00
|
|
|
LIBPATH="`readlink -f $${LIBPATH}`"; \
|
2022-06-25 00:19:01 +02:00
|
|
|
if [ "$${LIBPATH}" = "" ]; then \
|
|
|
|
echo "LIBPATH empty after trying to resolve symlink $${OLD_LIBPATH}" 1>&2; \
|
|
|
|
exit 1; \
|
|
|
|
fi; \
|
2012-05-07 15:02:19 +02:00
|
|
|
elif test -f $${LIBPATH}; then \
|
|
|
|
$(INSTALL) -D -m0755 $${LIBPATH} $(TARGET_DIR)/$${DESTDIR}/$${LIBNAME}; \
|
2017-02-07 22:56:47 +01:00
|
|
|
break ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
else \
|
|
|
|
exit -1; \
|
|
|
|
fi; \
|
|
|
|
done; \
|
2015-10-04 13:35:08 +02:00
|
|
|
done
|
2010-07-28 00:08:13 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# 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.
|
|
|
|
#
|
2017-02-07 22:56:40 +01:00
|
|
|
# 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
|
2010-07-28 00:08:13 +02:00
|
|
|
# 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.
|
|
|
|
#
|
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.
|
2017-02-07 22:56:45 +01:00
|
|
|
# Once the link destination is valid again, it can be simplified to
|
|
|
|
# remove the dependency on intermediate directory symlinks.
|
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
|
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
|
|
|
#
|
2016-05-10 16:01:37 +02:00
|
|
|
# Then, if the selected architecture variant is not the default one
|
|
|
|
# (i.e, if SYSROOT_DIR != ARCH_SYSROOT_DIR), then we :
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
2016-05-10 16:01:37 +02:00
|
|
|
# * Import the header files from the default architecture
|
2010-07-28 00:08:13 +02:00
|
|
|
# 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.
|
|
|
|
#
|
2016-05-10 16:01:37 +02:00
|
|
|
# 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.
|
2012-05-07 15:02:19 +02:00
|
|
|
#
|
2011-10-02 21:20:09 +02:00
|
|
|
# Note that the 'locale' directories are not copied. They are huge
|
|
|
|
# (400+MB) in CodeSourcery toolchains, and they are not really useful.
|
|
|
|
#
|
2010-07-28 00:08:13 +02:00
|
|
|
# $1: main sysroot directory of the toolchain
|
|
|
|
# $2: arch specific sysroot directory of the toolchain
|
|
|
|
# $3: arch specific subdirectory in the sysroot
|
2013-08-23 00:59:35 +02:00
|
|
|
# $4: directory of libraries ('lib', 'lib32' or 'lib64')
|
2012-05-07 15:02:19 +02:00
|
|
|
# $5: support lib directories (for toolchains storing libgcc_s,
|
|
|
|
# libstdc++ and other gcc support libraries outside of the
|
|
|
|
# sysroot)
|
2010-07-28 00:08:13 +02:00
|
|
|
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)" ; \
|
2012-05-07 15:02:19 +02:00
|
|
|
SUPPORT_LIB_DIR="$(strip $5)" ; \
|
2013-08-23 00:59:35 +02:00
|
|
|
for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
|
2017-02-07 22:56:38 +01:00
|
|
|
if [ ! -d $${ARCH_SYSROOT_DIR}/$$i ] ; then \
|
|
|
|
continue ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
fi ; \
|
2017-02-07 22:56:40 +01:00
|
|
|
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 ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
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}) ; \
|
Makefile: make-4.3 now longer un-escapes \# in macros
make-4.3 shipped with a backward incompatible change in how sharp signs
are handled in macros. Previously, up to make 4.2, the sharp sign would
always start a comment, unless backslash-escaped, even in a macro or a
fucntion call.
Now, the sharp sign is no longer starting a comment when it appears
inside such a macro or function call. This behaviour was supposed to be
in force since 3.81, but was not; 4.3 fixed the code to match the doc.
As such, use of external toolchains is broken, as we use the sharp sign
in the copy_toolchain_sysroot macro, in shell variable expansion to
strip off any leading /: ${target\#/}.
Fix that by applying the workaround suggested in the release annoucement
[0], by using a variable to hold a sharp sign.
[0] https://lists.gnu.org/archive/html/info-gnu/2020-01/msg00004.html
Signed-off-by: Yaroslav Syrytsia <me@ys.lc>
[yann.morin.1998@free.fr:
- move the SHARP_SIGN definition out of Makefile and into support/
- expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-03-30 15:41:37 +02:00
|
|
|
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 ; \
|
Makefile: make-4.3 now longer un-escapes \# in macros
make-4.3 shipped with a backward incompatible change in how sharp signs
are handled in macros. Previously, up to make 4.2, the sharp sign would
always start a comment, unless backslash-escaped, even in a macro or a
fucntion call.
Now, the sharp sign is no longer starting a comment when it appears
inside such a macro or function call. This behaviour was supposed to be
in force since 3.81, but was not; 4.3 fixed the code to match the doc.
As such, use of external toolchains is broken, as we use the sharp sign
in the copy_toolchain_sysroot macro, in shell variable expansion to
strip off any leading /: ${target\#/}.
Fix that by applying the workaround suggested in the release annoucement
[0], by using a variable to hold a sharp sign.
[0] https://lists.gnu.org/archive/html/info-gnu/2020-01/msg00004.html
Signed-off-by: Yaroslav Syrytsia <me@ys.lc>
[yann.morin.1998@free.fr:
- move the SHARP_SIGN definition out of Makefile and into support/
- expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-03-30 15:41:37 +02:00
|
|
|
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 ; \
|
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 ; \
|
2017-02-07 22:56:45 +01:00
|
|
|
$(call simplify_symlink,$$i,$(STAGING_DIR)) ; \
|
2017-02-07 22:56:43 +01:00
|
|
|
done ; \
|
|
|
|
fi ; \
|
2021-08-26 21:34:24 +02:00
|
|
|
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 ; \
|
2016-05-10 16:01:37 +02:00
|
|
|
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 ; \
|
2016-01-12 18:49:38 +01:00
|
|
|
fi ; \
|
2016-05-10 16:01:37 +02:00
|
|
|
mkdir -p `dirname $(STAGING_DIR)/$${ARCH_SUBDIR}` ; \
|
2017-02-07 22:56:42 +01:00
|
|
|
relpath="$(call relpath_prefix,$${ARCH_SUBDIR})./" ; \
|
2016-05-10 16:01:37 +02:00
|
|
|
ln -s $${relpath} $(STAGING_DIR)/$${ARCH_SUBDIR} ; \
|
|
|
|
echo "Symlinking $(STAGING_DIR)/$${ARCH_SUBDIR} -> $${relpath}" ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
fi ; \
|
2012-05-07 15:02:19 +02:00
|
|
|
if test -n "$${SUPPORT_LIB_DIR}" ; then \
|
|
|
|
cp -a $${SUPPORT_LIB_DIR}/* $(STAGING_DIR)/lib/ ; \
|
|
|
|
fi ; \
|
2022-05-17 12:32:12 +02:00
|
|
|
find $(STAGING_DIR) -type d -print0 | xargs -0 chmod 755
|
2010-07-28 00:08:13 +02:00
|
|
|
|
2014-03-01 15:53:01 +01:00
|
|
|
#
|
|
|
|
# Check the specified kernel headers version actually matches the
|
|
|
|
# version in the toolchain.
|
|
|
|
#
|
2019-09-24 13:46:11 +02:00
|
|
|
# $1: build directory
|
|
|
|
# $2: sysroot directory
|
|
|
|
# $3: kernel version string, in the form: X.Y
|
toolchain: allow using custom headers newer than latest known ones
When Buildroot is released, it knows up to a certain kernel header
version, and no later. However, it is possible that an external
toolchain will be used, that uses headers newer than the latest version
Buildroot knows about.
This may also happen when testing a development, an rc-class, or a newly
released kernel, either in an external toolchain, or with an internal
toolchain with custom headers (same-as-kernel, custom version, custom
git, custom tarball).
In the current state, Buildroot would refuse to use such toolchains,
because the test is for strict equality.
We'd like to make that situation possible, but we also want the user not
to be lenient at the same time, and select the right headers version
when it is known.
So, we add a new Kconfig blind option that the latest kernel headers
version selects. This options is then used to decide whether we do a
strict or loose check of the kernel headers.
Suggested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[yann.morin.1998@free.fr:
- only do a loose check for the latest version
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-15 19:29:07 +01:00
|
|
|
# $4: test to do for the latest kernel version, 'strict' or 'loose'
|
|
|
|
# always 'strict' if this is not the latest version.
|
2014-03-01 15:53:01 +01:00
|
|
|
#
|
|
|
|
check_kernel_headers_version = \
|
toolchain: allow using custom headers newer than latest known ones
When Buildroot is released, it knows up to a certain kernel header
version, and no later. However, it is possible that an external
toolchain will be used, that uses headers newer than the latest version
Buildroot knows about.
This may also happen when testing a development, an rc-class, or a newly
released kernel, either in an external toolchain, or with an internal
toolchain with custom headers (same-as-kernel, custom version, custom
git, custom tarball).
In the current state, Buildroot would refuse to use such toolchains,
because the test is for strict equality.
We'd like to make that situation possible, but we also want the user not
to be lenient at the same time, and select the right headers version
when it is known.
So, we add a new Kconfig blind option that the latest kernel headers
version selects. This options is then used to decide whether we do a
strict or loose check of the kernel headers.
Suggested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[yann.morin.1998@free.fr:
- only do a loose check for the latest version
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-15 19:29:07 +01:00
|
|
|
if ! support/scripts/check-kernel-headers.sh $(1) $(2) $(3) \
|
|
|
|
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
|
|
|
|
then \
|
2019-11-12 21:21:17 +01:00
|
|
|
exit 1; \
|
|
|
|
fi
|
2014-03-01 15:53:01 +01:00
|
|
|
|
2015-08-04 20:00:35 +02:00
|
|
|
#
|
|
|
|
# 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)" ; \
|
2015-08-13 14:13:23 +02:00
|
|
|
if [ -z "$${expected_version}" ]; then \
|
2016-11-24 00:40:34 +01:00
|
|
|
exit 0 ; \
|
2015-08-13 14:13:23 +02:00
|
|
|
fi; \
|
2017-03-09 09:01:36 +01:00
|
|
|
real_version=`$(1) -dumpversion` ; \
|
2020-06-11 01:53:12 +02:00
|
|
|
if [[ ! "$${real_version}." =~ ^$${expected_version}\. ]] ; then \
|
2015-08-09 13:11:42 +02:00
|
|
|
printf "Incorrect selection of gcc version: expected %s.x, got %s\n" \
|
|
|
|
"$${expected_version}" "$${real_version}" ; \
|
2015-08-04 20:00:35 +02:00
|
|
|
exit 1 ; \
|
|
|
|
fi
|
|
|
|
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
2012-11-03 18:47:50 +01:00
|
|
|
# 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.
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
|
|
|
# $1: Buildroot option name
|
|
|
|
# $2: feature description
|
|
|
|
#
|
|
|
|
check_glibc_feature = \
|
2013-07-17 22:30:47 +02:00
|
|
|
if [ "$($(1))" != "y" ] ; then \
|
2010-07-28 00:08:13 +02:00
|
|
|
echo "$(2) available in C library, please enable $(1)" ; \
|
|
|
|
exit 1 ; \
|
|
|
|
fi
|
|
|
|
|
2012-11-03 18:47:50 +01:00
|
|
|
#
|
|
|
|
# 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 \
|
2015-05-03 17:39:16 +02:00
|
|
|
echo "RPC support available in C library, please enable BR2_TOOLCHAIN_EXTERNAL_INET_RPC" ; \
|
2012-11-03 18:47:50 +01:00
|
|
|
exit 1 ; \
|
|
|
|
fi ; \
|
|
|
|
if [ "$(BR2_TOOLCHAIN_HAS_NATIVE_RPC)" = "y" -a "$${IS_IN_LIBC}" != "y" ] ; then \
|
2015-05-03 17:39:16 +02:00
|
|
|
echo "RPC support not available in C library, please disable BR2_TOOLCHAIN_EXTERNAL_INET_RPC" ; \
|
2012-11-03 18:47:50 +01:00
|
|
|
exit 1 ; \
|
|
|
|
fi
|
|
|
|
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
|
|
|
# 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)"; \
|
2017-09-03 23:00:43 +02:00
|
|
|
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 \
|
2010-07-28 00:08:13 +02:00
|
|
|
echo "Incorrect selection of the C library"; \
|
|
|
|
exit -1; \
|
|
|
|
fi; \
|
2011-01-10 15:28:41 +01:00
|
|
|
$(call check_glibc_feature,BR2_USE_MMU,MMU support) ;\
|
2012-11-03 18:47:50 +01:00
|
|
|
$(call check_glibc_rpc_feature,$${SYSROOT_DIR})
|
2010-07-28 00:08:13 +02:00
|
|
|
|
2013-10-08 20:17:09 +02:00
|
|
|
#
|
|
|
|
# Check that the selected C library really is musl
|
|
|
|
#
|
2017-03-20 06:56:10 +01:00
|
|
|
# $1: cross-gcc path
|
|
|
|
# $2: cross-readelf path
|
2013-10-08 20:17:09 +02:00
|
|
|
check_musl = \
|
2017-03-20 06:56:10 +01:00
|
|
|
__CROSS_CC=$(strip $1) ; \
|
2018-07-04 23:42:57 +02:00
|
|
|
libc_a_path=`$${__CROSS_CC} -print-file-name=libc.a` ; \
|
|
|
|
if ! strings $${libc_a_path} | grep -q MUSL_LOCPATH ; then \
|
2013-10-08 20:17:09 +02:00
|
|
|
echo "Incorrect selection of the C library" ; \
|
|
|
|
exit -1; \
|
2018-07-04 23:42:57 +02:00
|
|
|
fi
|
2013-10-08 20:17:09 +02:00
|
|
|
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
|
|
|
# Check the conformity of Buildroot configuration with regard to the
|
|
|
|
# uClibc configuration of the external toolchain, for a particular
|
|
|
|
# feature.
|
|
|
|
#
|
2015-03-30 23:07:20 +02:00
|
|
|
# If 'Buildroot option name' ($2) is empty it means the uClibc option
|
|
|
|
# is mandatory.
|
|
|
|
#
|
2010-07-28 00:08:13 +02:00
|
|
|
# $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` ; \
|
2015-03-30 23:07:20 +02:00
|
|
|
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 ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
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)"; \
|
2011-12-31 16:15:43 +01:00
|
|
|
if ! test -f $${SYSROOT_DIR}/usr/include/bits/uClibc_config.h ; then \
|
2010-07-28 00:08:13 +02:00
|
|
|
echo "Incorrect selection of the C library"; \
|
|
|
|
exit -1; \
|
|
|
|
fi; \
|
|
|
|
UCLIBC_CONFIG_FILE=$${SYSROOT_DIR}/usr/include/bits/uClibc_config.h ; \
|
2011-01-10 15:28:41 +01:00
|
|
|
$(call check_uclibc_feature,__ARCH_USE_MMU__,BR2_USE_MMU,$${UCLIBC_CONFIG_FILE},MMU support) ;\
|
2015-03-30 23:07:21 +02:00
|
|
|
$(call check_uclibc_feature,__UCLIBC_HAS_LFS__,,$${UCLIBC_CONFIG_FILE},Large file support) ;\
|
2015-04-19 14:39:54 +02:00
|
|
|
$(call check_uclibc_feature,__UCLIBC_HAS_IPV6__,,$${UCLIBC_CONFIG_FILE},IPv6 support) ;\
|
2012-11-03 18:47:49 +01:00
|
|
|
$(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) ;\
|
2010-07-28 00:08:13 +02:00
|
|
|
$(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) ;\
|
2013-09-02 18:06:36 +02:00
|
|
|
$(call check_uclibc_feature,__PTHREADS_DEBUG_SUPPORT__,BR2_TOOLCHAIN_HAS_THREADS_DEBUG,$${UCLIBC_CONFIG_FILE},Thread debugging support) ;\
|
2016-03-15 17:40:38 +01:00
|
|
|
$(call check_uclibc_feature,__UCLIBC_HAS_THREADS_NATIVE__,BR2_TOOLCHAIN_HAS_THREADS_NPTL,$${UCLIBC_CONFIG_FILE},NPTL thread support)
|
2010-07-28 00:08:13 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Check that the Buildroot configuration of the ABI matches the
|
|
|
|
# configuration of the external toolchain.
|
|
|
|
#
|
2011-05-08 18:52:27 +02:00
|
|
|
# $1: cross-gcc path
|
2014-07-03 11:35:57 +02:00
|
|
|
# $2: cross-readelf path
|
2011-05-08 18:52:27 +02:00
|
|
|
#
|
2010-07-28 00:08:13 +02:00
|
|
|
check_arm_abi = \
|
2011-05-08 18:52:27 +02:00
|
|
|
__CROSS_CC=$(strip $1) ; \
|
|
|
|
EXT_TOOLCHAIN_TARGET=`LANG=C $${__CROSS_CC} -v 2>&1 | grep ^Target | cut -f2 -d ' '` ; \
|
2013-07-14 00:27:32 +02:00
|
|
|
if ! echo $${EXT_TOOLCHAIN_TARGET} | grep -qE 'eabi(hf)?$$' ; then \
|
|
|
|
echo "External toolchain uses the unsuported OABI" ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
exit 1 ; \
|
2013-07-17 22:30:48 +02:00
|
|
|
fi ; \
|
2015-06-26 19:33:20 +02:00
|
|
|
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*; \
|
2014-05-09 13:44:00 +02:00
|
|
|
abistr_$(BR2_ARM_EABI)='EABI'; \
|
|
|
|
abistr_$(BR2_ARM_EABIHF)='EABIhf'; \
|
|
|
|
echo "Incorrect ABI setting: $${abistr_y} selected, but toolchain is incompatible"; \
|
2013-07-17 22:30:48 +02:00
|
|
|
exit 1 ; \
|
2015-06-26 19:33:20 +02:00
|
|
|
fi ; \
|
|
|
|
rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
|
2010-07-28 00:08:13 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Check that the external toolchain supports C++
|
|
|
|
#
|
2011-05-08 18:52:27 +02:00
|
|
|
# $1: cross-g++ path
|
|
|
|
#
|
2010-07-28 00:08:13 +02:00
|
|
|
check_cplusplus = \
|
2011-05-08 18:52:27 +02:00
|
|
|
__CROSS_CXX=$(strip $1) ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
__HAS_CXX=`$${__CROSS_CXX} -v > /dev/null 2>&1 && echo y`; \
|
|
|
|
if [ "$${__HAS_CXX}" != "y" -a "$(BR2_INSTALL_LIBSTDCPP)" = y ] ; then \
|
2010-12-13 17:27:41 +01:00
|
|
|
echo "C++ support is selected but is not available in external toolchain" ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
exit 1 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
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 \
|
2010-07-28 00:08:13 +02:00
|
|
|
|
2019-11-02 19:00:51 +01:00
|
|
|
#
|
|
|
|
#
|
|
|
|
# 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 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
__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 \
|
2019-11-02 19:00:51 +01:00
|
|
|
echo "D language support is selected but is not available in external toolchain" ; \
|
|
|
|
exit 1 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
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 \
|
2019-11-02 19:00:51 +01:00
|
|
|
|
2016-07-03 15:47:44 +02:00
|
|
|
#
|
|
|
|
#
|
|
|
|
# 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 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
__HAS_FORTRAN=`printf 'program hello\n\tprint *, "Hello Fortran!\\\n"\nend program hello\n' | \
|
2023-07-25 02:43:22 +02:00
|
|
|
$${__CROSS_FC} -x f95 -ffree-form -o $${__o} - 2>/dev/null && echo y`; \
|
2023-07-06 19:18:33 +02:00
|
|
|
rm -f $${__o}* ; \
|
|
|
|
if [ "$${__HAS_FORTRAN}" != "y" -a "$(BR2_TOOLCHAIN_HAS_FORTRAN)" = y ] ; then \
|
2016-07-03 15:47:44 +02:00
|
|
|
echo "Fortran support is selected but is not available in external toolchain" ; \
|
|
|
|
exit 1 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
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 \
|
2016-07-03 15:47:44 +02:00
|
|
|
|
2019-03-28 19:48:15 +01:00
|
|
|
#
|
|
|
|
#
|
|
|
|
# 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 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
__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 \
|
2019-03-28 19:48:15 +01:00
|
|
|
echo "OpenMP support is selected but is not available in external toolchain"; \
|
|
|
|
exit 1 ; \
|
2023-07-06 19:18:33 +02:00
|
|
|
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 \
|
2019-03-28 19:48:15 +01:00
|
|
|
|
2010-07-28 00:08:13 +02:00
|
|
|
#
|
|
|
|
# Check that the cross-compiler given in the configuration exists
|
|
|
|
#
|
2011-05-08 18:52:27 +02:00
|
|
|
# $1: cross-gcc path
|
|
|
|
#
|
2010-07-28 00:08:13 +02:00
|
|
|
check_cross_compiler_exists = \
|
2011-05-08 18:52:27 +02:00
|
|
|
__CROSS_CC=$(strip $1) ; \
|
|
|
|
$${__CROSS_CC} -v > /dev/null 2>&1 ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
if test $$? -ne 0 ; then \
|
2011-05-08 18:52:27 +02:00
|
|
|
echo "Cannot execute cross-compiler '$${__CROSS_CC}'" ; \
|
2010-07-28 00:08:13 +02:00
|
|
|
exit 1 ; \
|
2010-12-13 17:27:38 +01:00
|
|
|
fi
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
|
|
|
|
#
|
2016-04-27 22:15:03 +02:00
|
|
|
# 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.
|
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.
|
2016-04-27 22:15:03 +02:00
|
|
|
# - Exclude toolchains which doesn't support --sysroot option.
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
#
|
|
|
|
# $1: cross-gcc path
|
2023-02-11 19:28:38 +01:00
|
|
|
# $1: toolchain cflags
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
#
|
|
|
|
check_unusable_toolchain = \
|
|
|
|
__CROSS_CC=$(strip $1) ; \
|
2023-02-11 19:28:38 +01:00
|
|
|
__TOOLCHAIN_CFLAGS=$(strip $2) ; \
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
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 ; \
|
2015-03-17 16:14:55 +01:00
|
|
|
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; \
|
2016-04-27 22:15:01 +02:00
|
|
|
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 ; \
|
2016-04-27 22:15:02 +02:00
|
|
|
fi ; \
|
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; \
|
2016-04-27 22:15:02 +02:00
|
|
|
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 ; \
|
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-13 10:28:20 +02:00
|
|
|
fi
|
2014-05-05 11:25:50 +02:00
|
|
|
|
2016-03-15 17:40:38 +01:00
|
|
|
#
|
|
|
|
# Check if the toolchain has SSP (stack smashing protector) support
|
|
|
|
#
|
|
|
|
# $1: cross-gcc path
|
toolchain: check the SSP option is known
Some toolchain vendors may have backported those options to older gcc
versions, and we have no way to know, so we have to check that the
user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with
a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted
string, so we can safely and easily assign it to a shell variable to
test and use it.
Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has
SSP strong;
- of the external pre-built toolchains, only the codesourcery-arm
one has a gcc-4.8 which lacks SSP strong, all the others have a
gcc >= 4.9;
- we'd still have to do the actual check for custom external
toolchains anyway.
So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single
case.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-03-12 13:09:34 +01:00
|
|
|
# $2: gcc ssp option
|
2016-03-15 17:40:38 +01:00
|
|
|
#
|
|
|
|
check_toolchain_ssp = \
|
|
|
|
__CROSS_CC=$(strip $1) ; \
|
2024-04-03 19:03:51 +02:00
|
|
|
__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` ; \
|
2016-03-15 17:40:38 +01:00
|
|
|
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 ; \
|
toolchain: check the SSP option is known
Some toolchain vendors may have backported those options to older gcc
versions, and we have no way to know, so we have to check that the
user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with
a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted
string, so we can safely and easily assign it to a shell variable to
test and use it.
Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has
SSP strong;
- of the external pre-built toolchains, only the codesourcery-arm
one has a gcc-4.8 which lacks SSP strong, all the others have a
gcc >= 4.9;
- we'd still have to do the actual check for custom external
toolchains anyway.
So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single
case.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-03-12 13:09:34 +01:00
|
|
|
__SSP_OPTION=$(2); \
|
|
|
|
if [ -n "$${__SSP_OPTION}" ] ; then \
|
2024-04-03 19:03:51 +02:00
|
|
|
if ! echo 'int main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \
|
toolchain: check the SSP option is known
Some toolchain vendors may have backported those options to older gcc
versions, and we have no way to know, so we have to check that the
user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with
a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted
string, so we can safely and easily assign it to a shell variable to
test and use it.
Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has
SSP strong;
- of the external pre-built toolchains, only the codesourcery-arm
one has a gcc-4.8 which lacks SSP strong, all the others have a
gcc >= 4.9;
- we'd still have to do the actual check for custom external
toolchains anyway.
So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single
case.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-03-12 13:09:34 +01:00
|
|
|
echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \
|
|
|
|
exit 1 ; \
|
|
|
|
fi; \
|
|
|
|
fi; \
|
2016-03-15 17:40:38 +01:00
|
|
|
rm -f $(BUILD_DIR)/.br-toolchain-test.tmp*
|
|
|
|
|
2014-05-05 11:25:50 +02:00
|
|
|
#
|
|
|
|
# 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
|
2017-02-07 22:56:42 +01:00
|
|
|
|
|
|
|
# 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
|
2017-02-07 22:56:44 +01:00
|
|
|
|
|
|
|
# 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
|