| Message ID | 1381652900-12516-1-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Accepted |
| Commit | 1247850d44daafa5c7835f26da88e347b330b536 |
| Headers | show |
On Sun, Oct 13, 2013 at 10:28 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > 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> > --- > Changes since v1: > > * Fix typos in the comments (Thomas DS) > * Rename function to check_unusable_toolchain (Thomas DS) > * Use -dumpmachine instead of -v and some nasty sed'ing (Thomas DS) > * Add quotes around $${vendor} (Thomas DS) > > toolchain/helpers.mk | 18 ++++++++++++++++++ > toolchain/toolchain-external/toolchain-external.mk | 1 + > 2 files changed, 19 insertions(+) Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> The Angstrom toolchains available at
Thomas> http://www.angstrom-distribution.org/toolchains/ are not usable as
Thomas> external toolchains in Buildroot, because they are not pure toolchains
Thomas> with just the C library, but instead complete SDKs with many
Thomas> cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
Thomas> more, approximately 200 MB of libraries).
Thomas> Buildroot cannot use such toolchains, and while this is documented in
Thomas> our manual, some users still try to do this. Today, one such user came
Thomas> on the IRC channel, reporting a build problem, which we started
Thomas> investigating, only to realize after a long time that he was using an
Thomas> Angstrom toolchain.
Thomas> To avoid this problem in the future, we explicitly check if the
Thomas> toolchain is from Angstrom by looking at the vendor part of the tuple
Thomas> exposed by the toolchain: as soon as it is
Thomas> <something>-angstrom-<something-else>, we reject the toolchain with an
Thomas> explanation.
Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Committed, thanks.
On 13/10/13 10:28, Thomas Petazzoni wrote: > 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. Just for my info, how is it possible that we cannot use such an Angstrom toolchain as an external toolchain, but it is possible to use a buildroot-generated one? We can also generate a host dir with loads of libs, and these are perfectly usable as external toolchain, right? Regards, Arnout > > 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. [snip]
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, > Just for my info, how is it possible that we cannot use such an > Angstrom toolchain as an external toolchain, but it is possible to use > a buildroot-generated one? We can also generate a host dir with loads > of libs, and these are perfectly usable as external toolchain, right? No, we can afaik only reuse a buildroot toolchain if it is "bare", E.G. no packages selected.
Peter, Arnout, On Tue, 22 Oct 2013 16:24:24 +0200, Peter Korsgaard wrote: > > Just for my info, how is it possible that we cannot use such an > > Angstrom toolchain as an external toolchain, but it is possible to use > > a buildroot-generated one? We can also generate a host dir with loads > > of libs, and these are perfectly usable as external toolchain, right? > > No, we can afaik only reuse a buildroot toolchain if it is "bare", > E.G. no packages selected. Yes, absolutely. Ideally, my check for "angstrom" toolchain shouldn't check for angstrom, but should instead validate that the toolchain is "pure" (i.e only the C library). Unfortunately, I don't quite see an easy and reliable way to make sure that the only libraries/headers provided are the ones of the C library. Thomas
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk index 95120cd..a8944ce 100644 --- a/toolchain/helpers.mk +++ b/toolchain/helpers.mk @@ -324,3 +324,21 @@ check_cross_compiler_exists = \ echo "Cannot execute cross-compiler '$${__CROSS_CC}'" ; \ exit 1 ; \ fi + +# +# Check for toolchains known not to work with Buildroot. For now, we +# only check for Angstrom toolchains, by looking at the vendor part of +# the host tuple. +# +# $1: cross-gcc path +# +check_unusable_toolchain = \ + __CROSS_CC=$(strip $1) ; \ + 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 diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk index b5b1ce7..d41cc7c 100644 --- a/toolchain/toolchain-external/toolchain-external.mk +++ b/toolchain/toolchain-external/toolchain-external.mk @@ -371,6 +371,7 @@ endif # type of C library and all C library features. define TOOLCHAIN_EXTERNAL_CONFIGURE_CMDS $(Q)$(call check_cross_compiler_exists,$(TOOLCHAIN_EXTERNAL_CC)) + $(Q)$(call check_unusable_toolchain,$(TOOLCHAIN_EXTERNAL_CC)) $(Q)LIBC_A_LOCATION=`readlink -f $$(LANG=C $(TOOLCHAIN_EXTERNAL_CC) -print-file-name=libc.a)` ; \ SYSROOT_DIR=`echo $${LIBC_A_LOCATION} | sed -r -e 's:(usr/)?lib(32|64)?/(.*/)?libc\.a::'` ; \ if test -z "$${SYSROOT_DIR}" ; then \
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> --- Changes since v1: * Fix typos in the comments (Thomas DS) * Rename function to check_unusable_toolchain (Thomas DS) * Use -dumpmachine instead of -v and some nasty sed'ing (Thomas DS) * Add quotes around $${vendor} (Thomas DS) toolchain/helpers.mk | 18 ++++++++++++++++++ toolchain/toolchain-external/toolchain-external.mk | 1 + 2 files changed, 19 insertions(+)