| Message ID | 1488308547-10114-1-git-send-email-vzakhar@synopsys.com |
|---|---|
| State | Rejected |
| Headers | show |
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@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
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@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
Hi Vineet, On Wed, 2017-03-01 at 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@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
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 ?
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
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.
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
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
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 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
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
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
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@synopsys.com> --- extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + extra/Configs/defconfigs/arc/defconfig | 1 + 2 files changed, 2 insertions(+)