28 Feb
2017
28 Feb
'17
7:02 p.m.
This commit enables getpt() support in ARC defconfigs as some packages
need it. E.g. we need this to be able to build xterm package as it uses
getpt().
As an example I can refer to buildroot autobuilds where xterm build is
failing when using prebuilt ARC toolchain (which in its turn uses uClibc
without getpt() support):
http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3…
Signed-off-by: Vlad Zakharov <vzakhar(a)synopsys.com>
---
extra/Configs/defconfigs/arc/arcv2_defconfig | 1 +
extra/Configs/defconfigs/arc/defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/extra/Configs/defconfigs/arc/arcv2_defconfig
b/extra/Configs/defconfigs/arc/arcv2_defconfig
index 383861f..a9d9891 100644
--- a/extra/Configs/defconfigs/arc/arcv2_defconfig
+++ b/extra/Configs/defconfigs/arc/arcv2_defconfig
@@ -16,6 +16,7 @@ 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_SV4_DEPRECATED=y
diff --git a/extra/Configs/defconfigs/arc/defconfig
b/extra/Configs/defconfigs/arc/defconfig
index d3773aa..9a76e7d 100644
--- a/extra/Configs/defconfigs/arc/defconfig
+++ b/extra/Configs/defconfigs/arc/defconfig
@@ -15,6 +15,7 @@ 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_SV4_DEPRECATED=y
--
2.7.4
1 Mar
1 Mar
3:24 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello,
On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
This commit enables getpt() support in ARC defconfigs
as some packages
need it. E.g. we need this to be able to build xterm package as it uses
getpt().
As an example I can refer to buildroot autobuilds where xterm build is
failing when using prebuilt ARC toolchain (which in its turn uses uClibc
without getpt() support):
http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3…
Signed-off-by: Vlad Zakharov <vzakhar(a)synopsys.com>
---
extra/Configs/defconfigs/arc/arcv2_defconfig | 1 +
extra/Configs/defconfigs/arc/defconfig | 1 +
2 files changed, 2 insertions(+)
That's more of a question for Waldemar: does it really makes sense to
have defconfigs for each architecture? I mean how do they differ
between each other?
For example, the ARC arcv2_defconfig and defconfig only differ by the
option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs.
Shouldn't be the solution used on ARM (removing all options to select
the compiler flags, and leave it to the user to pass the appropriate
options) be used as well ?
So, are they really useful? Shouldn't uclibc-ng instead come with just
one or two defconfigs, like a "minimal" one and "full-featured" one?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
6 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
Hello,
On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
Yeah that would work fine I guess !
This commit enables getpt() support in ARC
defconfigs as some packages
need it. E.g. we need this to be able to build xterm package as it uses
getpt().
As an example I can refer to buildroot autobuilds where xterm build is
failing when using prebuilt ARC toolchain (which in its turn uses uClibc
without getpt() support):
https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net…
Signed-off-by: Vlad Zakharov <vzakhar(a)synopsys.com>
---
extra/Configs/defconfigs/arc/arcv2_defconfig | 1 +
extra/Configs/defconfigs/arc/defconfig | 1 +
2 files changed, 2 insertions(+)
That's more of a question for Waldemar: does
it really makes sense to
have defconfigs for each architecture? I mean how do they differ
between each other?
For example, the ARC arcv2_defconfig and defconfig only differ by the
option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs.
Shouldn't be the solution used on ARM (removing all options to select
the compiler flags, and leave it to the user to pass the appropriate
options) be used as well ? So, are they really useful? Shouldn't uclibc-ng
instead come with just
one or two defconfigs, like a "minimal" one and "full-featured" one?
totally agree and I've historically been pushing back on patches from Alexey et
all where we wanted to enable toggles to get buildroot packages building. That was
a fair requirement on their part but it kept bloating uClibc for our typical
embedded use. But this idea of minimal vs. full featured is exactly what we need.
@Alexey / @vlad can we take this up please !
Thx,
-Vineet
Best regards,
Thomas
6:25 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi Vineet,
On Wed, 2017-03-01 at 10:00 -0800, Vineet Gupta wrote:
Those changes I made to make sure our prebuilt toolchain is useful for building
more packages. I.e. to be in one camp with Mentor's (AKA CodeSourcery) prebuilt
tools that are really capable.
On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
That means for building of our toolchain we'll need to have
separately stored "defconfigs" in some form. Let's see what Anton says on
that :)
And regardless of what mr Anton says having off-the-tree defconfigs is not the best idea
because with time options will go in and out and occasionally we'll have outdated
defconfigs.
Hello,
On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
Yeah that would work fine I guess !
This commit enables getpt() support in ARC defconfigs as some packages
need it. E.g. we need this to be able to build xterm package as it uses
getpt().
As an example I can refer to buildroot autobuilds where xterm build is
failing when using prebuilt ARC toolchain (which in its turn uses uClibc
without getpt() support):
https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net…
&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=ziY-j5w_cIfohygKzr-OKfk6T_9nr9g3b-
kimHZMkxg&s=Bi2mbuDCVZlzqIZy-ahLFXcNKXbqMMobAcwsnHR99yA&e=
Signed-off-by: Vlad Zakharov <vzakhar(a)synopsys.com>
---
extra/Configs/defconfigs/arc/arcv2_defconfig | 1 +
extra/Configs/defconfigs/arc/defconfig | 1 +
2 files changed, 2 insertions(+)
That's more of a question for Waldemar: does it really makes sense to
have defconfigs for each architecture? I mean how do they differ
between each other?
For example, the ARC arcv2_defconfig and defconfig only differ by the
option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs.
Shouldn't be the solution used on ARM (removing all options to select
the compiler flags, and leave it to the user to pass the appropriate
options) be used as well ?
So, are they really useful? Shouldn't uclibc-ng instead come with just
one or two defconfigs, like a "minimal" one and "full-featured" one?
totally agree and I've historically been pushing back on patches from Alexey et
all where we wanted to enable toggles to get buildroot packages building.
That was
a fair requirement on their part but it kept bloating uClibc for our typical
embedded use. But this idea of minimal vs. full featured is exactly what we need.
@Alexey / @vlad can we take this up please !
Probably Waldemar's opinion might be useful here.
@Waldemar are there any plans for busting arch-specific defconfigs in favor
to generic defconfigs like those "minimal" and "full" mentioned
above?
-Alexey
6:35 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 10:25 AM, Alexey Brodkin wrote:
I didn't read Thomas' proposal that way. IMHO it would be better to stage it by
first folding arch defconfigs into arch min/full and later if possible merge them
in arch independent min/full ?
That was
a fair requirement on their part but it kept bloating uClibc for our typical
embedded use. But this idea of minimal vs. full featured is exactly what we need.
@Alexey / @vlad can we take this up please !
Probably Waldemar's opinion might
be useful here.
@Waldemar are there any plans for busting arch-specific defconfigs in favor
to generic defconfigs like those "minimal" and "full" mentioned
above? 
6:57 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi everyone,
That means for building of our toolchain we'll need to have separately stored
"defconfigs" in some form. Let's see what Anton says on that :)
And regardless of what mr Anton says having off-the-tree defconfigs is not
the best idea because with time options will go in and out and occasionally
we'll have outdated defconfigs.
[AK] Not specifying architecture via uClibc config file is good for me - I
wanted this long ago, since I never understood why current approach was used in
the first place.
Out-of-tree defconfigs are not good, because it is not clear who would update
them in time. In addition that would create an additional coupling between
toolchain build scripts and uClibc - they now should be always synchronized,
which is a bad design. Defconfigs should be part of uClibc, toolchain build
scripts (and other uClibc builders) would just select one by its name - less
coupling, easier maintenance.
IMHO it should be OK to increase capabilities of prebuilt toolchain, that
Synopsys provides, to it would do more out of the box, at the expense of extra
bloat - it is not possible to please everyone, anyway. Those users, who are not
happy with "bloated" tools, can build tools themselves with configuration they
need. That said, I think there should be some common sense in what are the
features being enabled. I'd suggest that "full" feature configuration
should
enable those features which are required by at least one package in Buildroot
or there is some another clearly defined user of it. If we don't know where
feature is used - why enable it?
Anton
building.
Those changes I made to make sure our prebuilt toolchain is useful for
building more packages. I.e. to be in one camp with Mentor's (AKA
CodeSourcery) prebuilt tools that are really capable.
>
That's more of a question for Waldemar: does it really makes sense
> to have defconfigs for each architecture? I mean how do they differ
> between each other?
>
> For example, the ARC arcv2_defconfig and defconfig only differ by
> the option CONFIG_ARC_CPU_HS, whose only purpose is to pass -
mcpu=archs.
Shouldn't be the solution used on ARM (removing all options to
select the compiler flags, and leave it to the user to pass the
appropriate
options) be used as well ?
Yeah that would work fine I guess !
So, are they really useful? Shouldn't uclibc-ng instead come with
just one or two defconfigs, like a "minimal" one and "full-featured"
one?
totally agree and I've historically been pushing back on patches from
Alexey et all where we wanted to enable toggles to get buildroot packages
That was
a fair requirement on their part but it kept bloating uClibc for our
typical embedded use. But this idea of minimal vs. full featured is exactly
what we need.
@Alexey / @vlad can we take this up please !
Probably Waldemar's opinion might be useful here.
@Waldemar are there any plans for busting arch-specific defconfigs in favor
to generic defconfigs like those "minimal" and "full" mentioned
above?
-Alexey
7:10 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 10:57 AM, Anton Kolesov wrote:
> That means for building of our toolchain we'll
need to have separately stored
> "defconfigs" in some form. Let's see what Anton says on that :)
But why is that - as long as buildroot (or other build systems) pass the right cpu
flags - why do you need a seperate config ?
> And regardless of what mr Anton says having
off-the-tree defconfigs is not
> the best idea because with time options will go in and out and occasionally
> we'll have outdated defconfigs.
The whole out-of-tree defconfig approach is nonsense - lets not discuss it !
[AK] Not specifying architecture via uClibc config
file is good for me - I
wanted this long ago, since I never understood why current approach was used in
the first place.
7:28 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi,
Vineet Gupta wrote,
On 03/01/2017 10:57 AM, Anton Kolesov wrote:
I am not really sure I understand the discussion completely.
I think we discuss two points here.
Point 1.:
Rules.mak and some default CFLAGS/LDFLAGS passed to the compile and
linking of code. I favour removing any specific -march/-mcpu/-mtune
stuff, as we have done in the past for ARM/MIPS.
So if ARC people like to remove this:
ifeq ($(TARGET_ARCH),arc)
CPU_CFLAGS-$(CONFIG_ARC_CPU_700) += -mA7
CPU_CFLAGS-$(CONFIG_ARC_CPU_HS) += -mcpu=archs
CPU_LDFLAGS-y += $(CPU_CFLAGS) -marclinux
endif
I would say, yes, good thing. The toolchain defaults should be
correctly set, no need to overwrite it inside uClibc-ng buildsystem.
Point 2.:
The files in extra/Configs/defconfigs/ and its use-cases.
I haven't touched or used any files here, because most of them just
contain TARGET_<arch>=y
I would rather vote either to completely remove this directory or
use it in the same way for all architectures.
At the moment only ARC, OR1K and NDS32 use full defconfigs:
wc -l uClibc-ng-git/extra/Configs/defconfigs/*/*
1 uClibc-ng-git/extra/Configs/defconfigs/alpha/defconfig
39 uClibc-ng-git/extra/Configs/defconfigs/arc/arcv2_defconfig
38 uClibc-ng-git/extra/Configs/defconfigs/arc/defconfig
38 uClibc-ng-git/extra/Configs/defconfigs/arc/tb10x_defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/arm/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/avr32/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/bfin/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/cris/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/frv/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/h8300/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/hppa/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/i386/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/ia64/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/m68k/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/metag/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/microblaze/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/mips/defconfig
167 uClibc-ng-git/extra/Configs/defconfigs/nds32/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/nios2/defconfig
236 uClibc-ng-git/extra/Configs/defconfigs/or1k/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/powerpc/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/sh/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/sparc/defconfig
1 uClibc-ng-git/extra/Configs/defconfigs/x86_64/defconfig
537 total
I think only the ARC defconfigs are really used anywhere.
All projects I know of, using uClibc-ng as a C library to create a
cross-toolchain are using some kind of own defconfigs and generated
fragments.
In OpenADK I have some target/<arch>/uclibc-ng.config for every
architecture with sane defaults to regular run and test uClibc-ng
based systems in emulators or on real hardware.
This is used in embedded-test to do regression testing.
Buildroot has some minimal defconfig and a developer can enable or
disable some features (RPC, WCHAR, Locales, ..).
I think a developer can also supply his own uClibc-ng config
fragment.
OpenWrt/LEDE use some own defconfigs.
To have a good compatibility for a lot of applications the ARC
Synopsis toolchains might use the existing Buildroot defaults, which
allows to build a lot of software packages. We have seen before the
last release, a lot of packages fail to compile, because the
internal buildroot toolchain uses more features than the external
Synopsis toolchain. (UCLIBC_HAS_GETPT, ..)
If the default creates to big systems, Synopsis can use minimal
configs and fix any autobuild issues ;)
I think any external toolchain builders should create their own
config and the uClibc-ng project should not provide any defconfigs
anymore. Indeed when someone just use Kconfig defaults he/she should always
end with a known to work toolchain.
I still think we have too much different config possibilities and if
we find some, which can be removed, I always vote for it.
Best regards
Waldemar
> That means for building of our toolchain
we'll need to have separately stored
> "defconfigs" in some form. Let's see what Anton says on that :)
But why is that - as long as buildroot (or other build systems) pass the right cpu
flags - why do you need a seperate config ?
> And regardless of what mr Anton says having
off-the-tree defconfigs is not
> the best idea because with time options will go in and out and occasionally
> we'll have outdated defconfigs.
The whole out-of-tree defconfig approach is nonsense - lets not discuss it !
> [AK] Not specifying architecture via uClibc config file is good for me - I
> wanted this long ago, since I never understood why current approach was used in
> the first place.
8:25 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello,
On Wed, 1 Mar 2017 18:25:35 +0000, Alexey Brodkin wrote:
That means for building of our toolchain we'll
need to have
separately stored "defconfigs" in some form. Let's see what Anton says on
that :)
And regardless of what mr Anton says having off-the-tree defconfigs is not the best idea
because with time options will go in and out and occasionally we'll have outdated
defconfigs.
What would they be off-tree?
What I meant is that when you look at the per architecture defconfigs,
they are also all exactly the same, except for the TARGET_<foo> option.
So instead of having this big duplication, my suggestion is to get rid
of architecture-specific defconfig, and just have a few
architecture-independent defconfig, addressing common use cases (such
as "minimal" and "feature full").
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
9:30 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi Thomas,
On Wed, 2017-03-01 at 21:25 +0100, Thomas Petazzoni wrote:
Hello,
On Wed, 1 Mar 2017 18:25:35 +0000, Alexey Brodkin wrote:
That was exactly my understanding :)
Speaking of "defconfigs" I really meant something that we may use
for building our toolchain outside of Buildroot if we want something that
differs from uClibc's defaults/defconfig - and most probably we'll need
something
either to add to uClibc's minimal_defconfig or exclude from _maximal_defconfig.
Otherwise how may we be in control of libc in our "reference" toolchain?
-Alexey
That means for building of our toolchain we'll need to have
separately stored "defconfigs" in some form. Let's see what Anton says on
that :)
And regardless of what mr Anton says having off-the-tree defconfigs is not the best
idea
because with time options will go in and out and occasionally we'll have outdated
defconfigs.
What would they be off-tree?
What I meant is that when you look at the per architecture defconfigs,
they are also all exactly the same, except for the TARGET_<foo> option.
So instead of having this big duplication, my suggestion is to get rid
of architecture-specific defconfig, and just have a few
architecture-independent defconfig, addressing common use cases (such
as "minimal" and "feature full").
9:45 p.m.
New subject: [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello,
On Wed, 1 Mar 2017 21:30:31 +0000, Alexey Brodkin wrote:
Speaking of "defconfigs" I really meant
something that we may use
for building our toolchain outside of Buildroot if we want something that
differs from uClibc's defaults/defconfig - and most probably we'll need
something
either to add to uClibc's minimal_defconfig or exclude from _maximal_defconfig.
Otherwise how may we be in control of libc in our "reference" toolchain?
A defconfig is what it is: a configuration provided as an example.
Nothing forces you to use it. It's just an example.
Buildroot doesn't use any of the uClibc-ng defconfigs. Buildroot has
its own configuration for uClibc. You could just do the same for your
reference toolchain.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
2607
days inactive
2608
days old
10 comments
6 participants
participants (6)
-
Alexey Brodkin -
Anton Kolesov -
Thomas Petazzoni -
Vineet Gupta -
Vlad Zakharov -
Waldemar Brodkorb