ARC: Enable getpt() support in ARC defconfigs
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
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
--- extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + extra/Configs/defconfigs/arc/defconfig | 1 + 2 files changed, 2 insertions(+)
extra/Configs/defconfigs/arc/arcv2_defconfig +1 -0
@@ -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
extra/Configs/defconfigs/arc/defconfig +1 -0
@@ -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
Signature · 1 line
2.7.4
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Hello,
Quoted 9 lines · 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 usesgetpt().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
Quoted 5 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Quoted 21 lines · Thomas Petazzoni
Hello,
Quoted 9 lines · 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 usesgetpt().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=Quoted 5 lines
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?
Quoted 5 lines
For example, the ARC
arcv2_defconfigand defconfig only differ by the optionCONFIG_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 !
Quoted 2 lines
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
Quoted 4 lines
Best regards,
Thomas
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Hi Vineet,
Quoted 26 lines · Vineet Gupta
Quoted 25 lines · Thomas Petazzoni
Hello,
Quoted 12 lines · 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 usesgetpt().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
withoutgetpt()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=?Quoted 5 lines
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?
Quoted 7 lines
Quoted 5 lines
For example, the ARC
arcv2_defconfigand defconfig only differ by the optionCONFIG_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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines
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
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Quoted 7 lines · Alexey Brodkin
Quoted 4 lines
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 ?
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
In reply to Alexey BrodkinHi everyone,
Quoted 12 lines
Quoted 6 lines
Quoted 6 lines
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_defconfigand defconfig only differ by the optionCONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs.
Quoted 5 lines
Quoted 4 lines
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 ?
Quoted 8 lines
Quoted 1 line
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
Quoted 24 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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 exactlywhat we need.
Quoted 1 line
@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
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Quoted 2 lines · Anton Kolesov
Quoted 2 lines
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 ?
Quoted 3 lines
Quoted 3 lines
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 !
Quoted 3 lines
[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.
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Hi,
Vineet Gupta wrote,
Quoted 16 lines · Anton Kolesov
Quoted 2 lines
Quoted 2 lines
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 ?
Quoted 3 lines
Quoted 3 lines
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 !
Quoted 3 lines
[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) -marclinuxendif
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
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
In reply to Alexey BrodkinHello,
Quoted 6 lines · Alexey Brodkin
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Hi Thomas,
Quoted 14 lines · Thomas Petazzoni
Hello,
Quoted 7 lines · Alexey Brodkin
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?
Quoted 7 lines
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
PATCH 1/1 ARC: Enable getpt() support in ARC defconfigs
Hello,
Quoted 6 lines · Alexey Brodkin
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_defconfigor 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com