[PATCH] ARC: Enable getpt() support in ARC defconfigs

[PATCH] ARC: Enable getpt() support in ARC defconfigs

[Vlad Zakharov]

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/28a92049a6ceef005787c5779f77ecf3fe8ad642/build-end.log

Signed-off-by: Vlad Zakharov <vzakhar at 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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Thomas Petazzoni]

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/28a92049a6ceef005787c5779f77ecf3fe8ad642/build-end.log
> 
> Signed-off-by: Vlad Zakharov <vzakhar at 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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Vineet Gupta]

On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
> 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):
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_28a_28a92049a6ceef005787c5779f77ecf3fe8ad642_build-2Dend.log&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 at 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 ?

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 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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-03-01@10:00 -0800, Vineet Gupta wrote:
> On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
> > 
> > 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):
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_28a_28a92049a6ceef005787c5779f77ecf3fe8ad642_build-2Dend.log
> > > &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 at 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 ?
> 
> Yeah that would work fine I guess !

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.

> > 
> > 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.

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 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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Vineet Gupta]

On 03/01/2017 10:25 AM, Alexey Brodkin wrote:
>> 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?

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 ?

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Anton Kolesov]

Hi everyone,

> > > 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 !
> 
> 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

> 
> > >
> > > 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.
> 
> 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 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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Vineet Gupta]

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.

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Waldemar Brodkorb]

Hi,
Vineet Gupta wrote,

> 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.
 
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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Thomas Petazzoni]

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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Alexey Brodkin]

Hi Thomas,

On Wed, 2017-03-01@21:25 +0100, Thomas Petazzoni wrote:
> 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").

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

[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Thomas Petazzoni]

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