From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] Disabling Synopsys ARC pre-built toolchains in Buildroot
Date: Fri, 17 Apr 2015 08:49:37 +0000 [thread overview]
Message-ID: <1429260577.2846.27.camel@synopsys.com> (raw)
In-Reply-To: <20150410112156.6b0e42f7@free-electrons.com>
Hi Thomas,
On Fri, 2015-04-10 at 11:21 +0200, Thomas Petazzoni wrote:
> Hello Alexey,
>
> In commit 2b93fe5374ae4f8337e1f7ae32be4d72dd94cb3c, you added the
> support for pre-built ARC toolchains from Synopsys, which was a very
> useful change.
>
> However, right now, I wonder if we should not get rid of those
> toolchains: they use a uClibc configuration that is too different from
> the default one of Buildroot, causing numerous build failures in the
> autobuilders. Those failures are due to:
>
> * Missing libutil stub (UCLIBC_HAS_LIBUTIL option)
>
> http://autobuild.buildroot.org/results/ce3/ce39eb9b9ece0968563641fb2207099d1a37b191/
>
> * Missing program_invocation_name (UCLIBC_HAS_PROGRAM_INVOCATION_NAME
> option)
>
> http://autobuild.buildroot.org/results/154/1546d909e606daefd41b87dece94d642c0fdeba4/
> http://autobuild.buildroot.org/results/bd5/bd54581d7b0cc73bc501072d27e870a443dfce79/
>
> * Missing ifaddrd support (UCLIBC_SUPPORT_AI_ADDRCONFIG option)
>
> http://autobuild.buildroot.org/results/134/134e78ef1fa87f7fbf26c23ec5dfc68785d79613/
>
> There are too many of those issues affecting too many packages for us
> to reasonably patch all of them.
>
> Could you work internally to prepare a new version of those toolchains,
> that has at least these three additional options enabled?
>
> In the mean time, unless you have an objection, I will mark those
> toolchains as disabled in Buildroot.
Looks like our pre-built tools didn't work as good as I expected. Indeed
there're so many options in uClibc that it's hard to match requirements
of all the different apps we build.
And at that point I'm not sure if there's a solution which satisfies
both sides (I mean Buildroot and Synopsys people). And that's not about
either side if bad or good.
Personally I'd like to have proven by many autobuild tests Buildroot
config as a defconfig for ARC. But there're following issues I may see:
[1] Buildroot defconfigs for uClibc are not generated by "make
savedefconfig" which makes it very hard to understand which options are
enabled and which are disabled compared to defaults.
[2] Buildroot defconfig may contain options (disabled or enabled
compared to defaults) that might be harmful (in run-time issues like
performance degradation etc). Remember missing
UCLIBC_HAS_STRING_GENERIC_OPT. This is I think a reminder of early days
of Buildroot. And so blind use of Buildroot defconfig as defconfig for
ARC might not work well enough.
So probably for now removal or hiding of AC pre-built tools is the
ultimate solution in short-term. The next release of our tools is
scheduled on June-July this year and I hope to put required changes in
defconfigs by that time.
Still I think we all may benefit from observed situation.
For starters why don't we run at least "uClibc-snapshot.config" through
"make savedefconfig". So we'll have only differences from defaults.
That's what I got running "make savedefconfig" on the current
"uClibc-snapshot.config" note it's only 40 lines in length compared to
256 lines in "uClibc-snapshot.config":
--->8---
DO_C99_MATH=y
KERNEL_HEADERS="/usr/src/linux/include"
# LDSO_CACHE_SUPPORT is not set
# UCLIBC_STATIC_LDCONFIG is not set
LDSO_RUNPATH=y
LINUXTHREADS_OLD=y
MALLOC_GLIBC_COMPAT=y
UCLIBC_HAS_OBSTACK=y
UCLIBC_HAS_UTMPX=y
UCLIBC_HAS_UTMP=y
UCLIBC_SUSV2_LEGACY=y
UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV4_LEGACY=y
UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y
UCLIBC_HAS_GETPT=y
UCLIBC_HAS_LIBUTIL=y
UCLIBC_HAS_OBSOLETE_BSD_SIGNAL=y
UCLIBC_USE_NETLINK=y
UCLIBC_SUPPORT_AI_ADDRCONFIG=y
UCLIBC_HAS_RESOLVER_SUPPORT=y
UCLIBC_HAS_LIBRESOLV_STUB=y
UCLIBC_HAS_LIBNSL_STUB=y
UCLIBC_HAS_CTYPE_CHECKED=y
UCLIBC_HAS_HEXADECIMAL_FLOATS=y
UCLIBC_HAS_GLIBC_CUSTOM_PRINTF=y
# UCLIBC_HAS_STDIO_GETC_MACRO is not set
# UCLIBC_HAS_STDIO_PUTC_MACRO is not set
UCLIBC_HAS_FOPEN_EXCLUSIVE_MODE=y
UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
UCLIBC_HAS_PRINTF_M_SPEC=y
# UCLIBC_HAS_REGEX_OLD is not set
# UCLIBC_HAS_FNMATCH_OLD is not set
UCLIBC_HAS_NFTW=y
UCLIBC_HAS_FTW=y
UCLIBC_HAS_GNU_GLOB=y
RUNTIME_PREFIX="/"
DEVEL_PREFIX="/usr/"
UCLIBC_HAS_SSP=y
UCLIBC_BUILD_NOW=y
# DOSTRIP is not set
--->8---
BTW that's funny what says header of the current
"uClibc-snapshot.config" even though it's year 2015 and snapshots are
far behind 0.9.33 :)
--->8---
# Automatically generated make config: don't edit
# Version: 0.9.32-git
# Fri Jul 9 22:31:59 2010
--->8---
-Alexey
next prev parent reply other threads:[~2015-04-17 8:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 9:21 [Buildroot] Disabling Synopsys ARC pre-built toolchains in Buildroot Thomas Petazzoni
2015-04-17 8:49 ` Alexey Brodkin [this message]
2015-04-17 19:47 ` Arnout Vandecappelle
2015-04-22 10:47 ` Alexey Brodkin
2015-04-22 11:29 ` Thomas Petazzoni
2015-04-22 20:15 ` Arnout Vandecappelle
2015-04-23 15:26 ` Waldemar Brodkorb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1429260577.2846.27.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox