[1/2] uclibc-ng: enable fts in default config file.

Submitted by Adam Duskett on July 13, 2017, 2:25 p.m.

Details

Message ID 20170713142549.28078-1-aduskett@gmail.com
State New
Headers show

Commit Message

Adam Duskett July 13, 2017, 2:25 p.m.
currently there are a few packages in buildroot that are set to not
be selectable unless the user wishes to use glibc specifically because
the package uses fts.h.

uClibc actually does have a fts implimentation, and it's selectable in
uclib-menuconfig.  However; this has two issues with it:

1) Most users wouldn't know that there is even a uClibc-menuconfig
2) Even if the user does select fts support in uClibc-menuconfig, the
   packages that would now compile and work would still not be selectable
   because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.

Enabling fts support increases the size of uclibc by 75~kb according to
the menuconfig option.  This is a acceptable size increase to fix the
few packages that require fts.h support.

Signed-off-by: Adam Duskett <aduskett@gmail.com>
---
 package/uclibc/uClibc-ng.config | 1 +
 1 file changed, 1 insertion(+)

Comments

Thomas Petazzoni July 13, 2017, 5:32 p.m.
Hello,

On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:

> Enabling fts support increases the size of uclibc by 75~kb according to

75 KB, or 5-7 KB ?

Thomas
Adam Duskett July 13, 2017, 5:41 p.m.
75KB

On Thu, Jul 13, 2017 at 1:32 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
>
>> Enabling fts support increases the size of uclibc by 75~kb according to
>
> 75 KB, or 5-7 KB ?
>
Whoops! My bad.
7.5k according to the menuconfig help.

> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Thomas Petazzoni July 15, 2017, 9:44 a.m.
Hello,

On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
> currently there are a few packages in buildroot that are set to not
> be selectable unless the user wishes to use glibc specifically because
> the package uses fts.h.
> 
> uClibc actually does have a fts implimentation, and it's selectable in
> uclib-menuconfig.  However; this has two issues with it:
> 
> 1) Most users wouldn't know that there is even a uClibc-menuconfig
> 2) Even if the user does select fts support in uClibc-menuconfig, the
>    packages that would now compile and work would still not be selectable
>    because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
> 
> Enabling fts support increases the size of uclibc by 75~kb according to
> the menuconfig option.  This is a acceptable size increase to fix the
> few packages that require fts.h support.
> 
> Signed-off-by: Adam Duskett <aduskett@gmail.com>

Peter, what is your thought on enabling FTS by default in our uClibc-ng
configuration ?

Note that contrary to what Adam commit log says, the size increase is
7.5 KB.

Thanks,

Thomas
Peter Korsgaard July 15, 2017, 3:15 p.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
 >> currently there are a few packages in buildroot that are set to not
 >> be selectable unless the user wishes to use glibc specifically because
 >> the package uses fts.h.
 >> 
 >> uClibc actually does have a fts implimentation, and it's selectable in
 >> uclib-menuconfig.  However; this has two issues with it:
 >> 
 >> 1) Most users wouldn't know that there is even a uClibc-menuconfig
 >> 2) Even if the user does select fts support in uClibc-menuconfig, the
 >> packages that would now compile and work would still not be selectable
 >> because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
 >> 
 >> Enabling fts support increases the size of uclibc by 75~kb according to
 >> the menuconfig option.  This is a acceptable size increase to fix the
 >> few packages that require fts.h support.
 >> 
 >> Signed-off-by: Adam Duskett <aduskett@gmail.com>

 > Peter, what is your thought on enabling FTS by default in our uClibc-ng
 > configuration ?

 > Note that contrary to what Adam commit log says, the size increase is
 > 7.5 KB.

Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
it is a legacy BSD feature and it also isn't supported by musl.

It is easy to enable uClibc options, but difficult to disable them again
later (as users of the affected packages get caught).

Looking around, it seems we are only talking about 3 packages (if the
annotations are correct):

git grep -l 'fts.h' **/Config.in
package/libcgroup/Config.in
package/libselinux/Config.in
package/libsemanage/Config.in

Do we care enough for selinux users on uClibc (libcgroup seems to only
be an optional dependency for gst1-rtsp-server) to let all other
uClibc-ng users pay?
Adam Duskett July 15, 2017, 5:16 p.m.
Hello;

On Sat, Jul 15, 2017 at 11:15 AM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>  > Hello,
>  > On Thu, 13 Jul 2017 10:25:48 -0400, Adam Duskett wrote:
>  >> currently there are a few packages in buildroot that are set to not
>  >> be selectable unless the user wishes to use glibc specifically because
>  >> the package uses fts.h.
>  >>
>  >> uClibc actually does have a fts implimentation, and it's selectable in
>  >> uclib-menuconfig.  However; this has two issues with it:
>  >>
>  >> 1) Most users wouldn't know that there is even a uClibc-menuconfig
>  >> 2) Even if the user does select fts support in uClibc-menuconfig, the
>  >> packages that would now compile and work would still not be selectable
>  >> because they explicitly require BR2_TOOLCHAIN_USES_GLIBC.
>  >>
>  >> Enabling fts support increases the size of uclibc by 75~kb according to
>  >> the menuconfig option.  This is a acceptable size increase to fix the
>  >> few packages that require fts.h support.
>  >>
>  >> Signed-off-by: Adam Duskett <aduskett@gmail.com>
>
>  > Peter, what is your thought on enabling FTS by default in our uClibc-ng
>  > configuration ?
>
>  > Note that contrary to what Adam commit log says, the size increase is
>  > 7.5 KB.
>
> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
> it is a legacy BSD feature and it also isn't supported by musl.
>
Funny enough, musl's wiki is a bit dated.
http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_fts.h_not_included_.3F

"if glibc bug 15838 is fixed by adding an fts64 interface in glibc, we could
consider supporting it with a matching ABI in musl, but it seems more likely
that glibc will just deprecate this interface."

The thing is, bug 15838 WAS fixed a while ago, and fts has had a proper
64bit variant for a while.  Not sure why they are dragging their feet, but
that's another topic for another day.


> It is easy to enable uClibc options, but difficult to disable them again
> later (as users of the affected packages get caught).
>
> Looking around, it seems we are only talking about 3 packages (if the
> annotations are correct):
>
> git grep -l 'fts.h' **/Config.in
> package/libcgroup/Config.in
> package/libselinux/Config.in
> package/libsemanage/Config.in
>

True, but why should we deny uClibc users extra security?

> Do we care enough for selinux users on uClibc (libcgroup seems to only
> be an optional dependency for gst1-rtsp-server) to let all other
> uClibc-ng users pay?
>

I have a core-i5, 16 gigs of ram, and a 256gig Crucial MX200 SSD

Build times/sizes with all packages necessary to compile
already download, no compiler cache:

command ran:  time make uclibc

without FTS:

real 7m39.002s
user 15m30.321s
sys 2m6.026s
target: 856k
output/build/uclibc-1.0.25: 51196

with FTS:
real 7m18.378s
user 15m22.944s
sys 2m4.397s
target: 864K
output/build/uclibc-1.0.25: 51244

So, negligable difference in time to compile.
Negligable size difference.
The added benefit of being able to use SELinux, which
allows for better security.

Hardly a payment in my opinion. :)

> --
> Bye, Peter Korsgaard

Thanks!

Adam
Thomas Petazzoni July 15, 2017, 7:48 p.m.
Hello,

On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:

>  > Note that contrary to what Adam commit log says, the size increase is
>  > 7.5 KB.  
> 
> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
> it is a legacy BSD feature and it also isn't supported by musl.

Agreed.

> It is easy to enable uClibc options, but difficult to disable them again
> later (as users of the affected packages get caught).
> 
> Looking around, it seems we are only talking about 3 packages (if the
> annotations are correct):
> 
> git grep -l 'fts.h' **/Config.in
> package/libcgroup/Config.in
> package/libselinux/Config.in
> package/libsemanage/Config.in
> 
> Do we care enough for selinux users on uClibc (libcgroup seems to only
> be an optional dependency for gst1-rtsp-server) to let all other
> uClibc-ng users pay?

I would personally say no. The driving reason for Adam was to be able
to build the SELinux stuff. But indeed, if you're adding all the
SELinux overhead on your system, you most likely have the filesystem
space needed to switch to glibc.

So I'm fine if we decide to say "no". It should hopefully increase the
pressure on the upstream projects to move away from a legacy BSD
interface, and use the POSIX interface instead.

Best regards,

Thomas
Adam Duskett July 15, 2017, 8:09 p.m.
Hello;

On Sat, Jul 15, 2017 at 3:48 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
>
>>  > Note that contrary to what Adam commit log says, the size increase is
>>  > 7.5 KB.
>>
>> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>> it is a legacy BSD feature and it also isn't supported by musl.
>
> Agreed.
>
>> It is easy to enable uClibc options, but difficult to disable them again
>> later (as users of the affected packages get caught).
>>
>> Looking around, it seems we are only talking about 3 packages (if the
>> annotations are correct):
>>
>> git grep -l 'fts.h' **/Config.in
>> package/libcgroup/Config.in
>> package/libselinux/Config.in
>> package/libsemanage/Config.in
>>
>> Do we care enough for selinux users on uClibc (libcgroup seems to only
>> be an optional dependency for gst1-rtsp-server) to let all other
>> uClibc-ng users pay?
>
> I would personally say no. The driving reason for Adam was to be able
> to build the SELinux stuff. But indeed, if you're adding all the
> SELinux overhead on your system, you most likely have the filesystem
> space needed to switch to glibc.
>
Not only that, but as stated in the past, uClibc-ng is the default
toolchain for buildroot.  And as it sits, even if somebody did go in and
turn fts on in uclibc-ng, they still wouldn't be able to select the SELinux
packages.

> So I'm fine if we decide to say "no". It should hopefully increase the
> pressure on the upstream projects to move away from a legacy BSD
> interface, and use the POSIX interface instead.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Peter Korsgaard July 16, 2017, 3:53 p.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:

 >> > Note that contrary to what Adam commit log says, the size increase is
 >> > 7.5 KB.  
 >> 
 >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
 >> it is a legacy BSD feature and it also isn't supported by musl.

 > Agreed.

 >> It is easy to enable uClibc options, but difficult to disable them again
 >> later (as users of the affected packages get caught).
 >> 
 >> Looking around, it seems we are only talking about 3 packages (if the
 >> annotations are correct):
 >> 
 >> git grep -l 'fts.h' **/Config.in
 >> package/libcgroup/Config.in
 >> package/libselinux/Config.in
 >> package/libsemanage/Config.in
 >> 
 >> Do we care enough for selinux users on uClibc (libcgroup seems to only
 >> be an optional dependency for gst1-rtsp-server) to let all other
 >> uClibc-ng users pay?

 > I would personally say no. The driving reason for Adam was to be able
 > to build the SELinux stuff. But indeed, if you're adding all the
 > SELinux overhead on your system, you most likely have the filesystem
 > space needed to switch to glibc.

 > So I'm fine if we decide to say "no". It should hopefully increase the
 > pressure on the upstream projects to move away from a legacy BSD
 > interface, and use the POSIX interface instead.

Ok, agreed. Adam, sorry but we prefer to keep things as they
are. It should be fairly easy for uClibc-ng users wanting to enable
selinux to notice that they need to change to glibc instead based on the
comment:

comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
Waldemar Brodkorb July 16, 2017, 4:43 p.m.
Hi Peter, Thomas,
Peter Korsgaard wrote,

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
>  > Hello,
>  > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
> 
>  >> > Note that contrary to what Adam commit log says, the size increase is
>  >> > 7.5 KB.  
>  >> 
>  >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>  >> it is a legacy BSD feature and it also isn't supported by musl.
> 
>  > Agreed.
> 
>  >> It is easy to enable uClibc options, but difficult to disable them again
>  >> later (as users of the affected packages get caught).
>  >> 
>  >> Looking around, it seems we are only talking about 3 packages (if the
>  >> annotations are correct):
>  >> 
>  >> git grep -l 'fts.h' **/Config.in
>  >> package/libcgroup/Config.in
>  >> package/libselinux/Config.in
>  >> package/libsemanage/Config.in
>  >> 
>  >> Do we care enough for selinux users on uClibc (libcgroup seems to only
>  >> be an optional dependency for gst1-rtsp-server) to let all other
>  >> uClibc-ng users pay?
> 
>  > I would personally say no. The driving reason for Adam was to be able
>  > to build the SELinux stuff. But indeed, if you're adding all the
>  > SELinux overhead on your system, you most likely have the filesystem
>  > space needed to switch to glibc.
> 
>  > So I'm fine if we decide to say "no". It should hopefully increase the
>  > pressure on the upstream projects to move away from a legacy BSD
>  > interface, and use the POSIX interface instead.
> 
> Ok, agreed. Adam, sorry but we prefer to keep things as they
> are. It should be fairly easy for uClibc-ng users wanting to enable
> selinux to notice that they need to change to glibc instead based on the
> comment:
> 
> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"

But this is not the case, they don't need to switch to glibc.
The decision makes me sad, as it goes the opposite way I try to
develop in Buildroot. I added a lot of stuff f.e. to uClibc-ng to
allow to build and use systemd. The required systemd patches are
upstream. I regulary try to enable packages which are disabled for no
good reason for uClibc users. AutoFS next version will contain the
patch allowing to use uClibc-ng and libtirpc instead of Glibc.

And what about the people using an architecture which is not supported
by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
architectures? 

We enabled Wordexp recently and I would really love to see this
enabled, too. Could you rethink about your decision?

best regards
 Waldemar
Adam Duskett July 16, 2017, 5:40 p.m.
All;

On Sun, Jul 16, 2017 at 12:43 PM, Waldemar Brodkorb <wbx@openadk.org> wrote:
> Hi Peter, Thomas,
> Peter Korsgaard wrote,
>
>> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>>
>>  > Hello,
>>  > On Sat, 15 Jul 2017 17:15:51 +0200, Peter Korsgaard wrote:
>>
>>  >> > Note that contrary to what Adam commit log says, the size increase is
>>  >> > 7.5 KB.
>>  >>
>>  >> Hmm, 7.5KB isn't much - But fts isn't enabled by default in uClibc-nc,
>>  >> it is a legacy BSD feature and it also isn't supported by musl.
>>
>>  > Agreed.
>>
>>  >> It is easy to enable uClibc options, but difficult to disable them again
>>  >> later (as users of the affected packages get caught).
>>  >>
>>  >> Looking around, it seems we are only talking about 3 packages (if the
>>  >> annotations are correct):
>>  >>
>>  >> git grep -l 'fts.h' **/Config.in
>>  >> package/libcgroup/Config.in
>>  >> package/libselinux/Config.in
>>  >> package/libsemanage/Config.in
>>  >>
>>  >> Do we care enough for selinux users on uClibc (libcgroup seems to only
>>  >> be an optional dependency for gst1-rtsp-server) to let all other
>>  >> uClibc-ng users pay?
>>
>>  > I would personally say no. The driving reason for Adam was to be able
>>  > to build the SELinux stuff. But indeed, if you're adding all the
>>  > SELinux overhead on your system, you most likely have the filesystem
>>  > space needed to switch to glibc.
>>
>>  > So I'm fine if we decide to say "no". It should hopefully increase the
>>  > pressure on the upstream projects to move away from a legacy BSD
>>  > interface, and use the POSIX interface instead.
>>
>> Ok, agreed. Adam, sorry but we prefer to keep things as they
>> are. It should be fairly easy for uClibc-ng users wanting to enable
>> selinux to notice that they need to change to glibc instead based on the
>> comment:
>>
>> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
But that's simply not true.  uClibc-ng compiles it just fine if FTS is
turned on.
>
> But this is not the case, they don't need to switch to glibc.
> The decision makes me sad, as it goes the opposite way I try to
> develop in Buildroot. I added a lot of stuff f.e. to uClibc-ng to
> allow to build and use systemd. The required systemd patches are
> upstream. I regulary try to enable packages which are disabled for no
> good reason for uClibc users. AutoFS next version will contain the
> patch allowing to use uClibc-ng and libtirpc instead of Glibc.
>
> And what about the people using an architecture which is not supported
> by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> architectures?
>
This is also a good point.  Why would we deny uClibc-ng users security?
Glibc has a large history of CVE's:
https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html

uClibc is smaller and thus has a smaller attack vector, which is good
in conjuntion
with SELinux.

> We enabled Wordexp recently and I would really love to see this
> enabled, too. Could you rethink about your decision?
>
> best regards
>  Waldemar

Thanks!

Adam
Yann E. MORIN July 16, 2017, 6:46 p.m.
Adam, Waldemar, All,

On 2017-07-16 13:40 -0400, Adam Duskett spake thusly:
> On Sun, Jul 16, 2017 at 12:43 PM, Waldemar Brodkorb <wbx@openadk.org> wrote:
> > Peter Korsgaard wrote,
> >> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
[--SNIP--]
> >>  > So I'm fine if we decide to say "no". It should hopefully increase the
> >>  > pressure on the upstream projects to move away from a legacy BSD
> >>  > interface, and use the POSIX interface instead.
> >>
> >> Ok, agreed. Adam, sorry but we prefer to keep things as they
> >> are. It should be fairly easy for uClibc-ng users wanting to enable
> >> selinux to notice that they need to change to glibc instead based on the
> >> comment:
> >>
> >> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
> But that's simply not true.  uClibc-ng compiles it just fine if FTS is
> turned on.

I can see two issues there:

  - fts() is deprecated, obsoleted; it is not POSIX:
        http://pubs.opengroup.org/onlinepubs/9699919799/idx/if.html

  - external toolchain, uClibc-based: since fts is a deprecated
    interface, it is most probably that an external toolchain does not
    have it.

Besides, musl does not provide it, so the SELinux stuff is anyway not
avbailable to everyone.

People interested in having SELinux with non-glibc will have to provide
a patch against SELinux to be dsure they are usable, at least with musl,
which is a C library with good momentum.

[--SNIP--]
> > And what about the people using an architecture which is not supported
> > by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> > architectures?

*This* is a valid reason to add fts() to our internal uClibc
configuraiton. If anythong, this should be the only argument exposed to
add fts().

> This is also a good point.  Why would we deny uClibc-ng users security?
> Glibc has a large history of CVE's:
> https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html
> 
> uClibc is smaller and thus has a smaller attack vector, which is good

But unfortunately, uClibc-ng has far less exposure than glibc, so this
is also a security concern...

> in conjuntion
> with SELinux.
> 
> > We enabled Wordexp recently and I would really love to see this
> > enabled, too. Could you rethink about your decision?

I was initially writing this mail to argue in favour of adding fts(),
and now I am a little bit more suspicious, too. The only killing
argument for me is the one about archs without a glibc port. Those are
left out in the cold, and that's not nice...

Regards,
Yann E. MORIN.
Arnout Vandecappelle July 18, 2017, 7:24 p.m.
On 16-07-17 18:43, Waldemar Brodkorb wrote:
> Hi Peter, Thomas,
> Peter Korsgaard wrote,
[snip]
>> Ok, agreed. Adam, sorry but we prefer to keep things as they
>> are. It should be fairly easy for uClibc-ng users wanting to enable
>> selinux to notice that they need to change to glibc instead based on the
>> comment:
>>
>> comment "libselinux needs a glibc toolchain w/ threads, dynamic library"
> 
> But this is not the case, they don't need to switch to glibc.
> The decision makes me sad, as it goes the opposite way I try to
> develop in Buildroot.

 I'm with you on this one. If a package can work with uClibc, we really should
allow it.

 However, I don't think the solution is to bloat our default uClibc config with
features that are not useful for 99.82% of our packages. fts.h is not something
like IPv6 that is useful for a large number of packages.

 I also don't think we should add more options like BR2_ENABLE_LOCALE that copy
the uClibc config options.

 Perhaps the way to go is to have a BR2_TOOLCHAIN_UCLIBC_BLOAT_CONFIG option
that a user can set to indicate he wants to see packages that will not work with
our default uClibc config. That option could give a nice warning that this
configuration is not tested and YMMV.


> I added a lot of stuff f.e. to uClibc-ng to
> allow to build and use systemd. The required systemd patches are
> upstream. I regulary try to enable packages which are disabled for no
> good reason for uClibc users. AutoFS next version will contain the
> patch allowing to use uClibc-ng and libtirpc instead of Glibc.

 Patching packages so they work with uClibc is important too, but not relevant
to this discussion. Although indeed possibly the better option would be to patch
those four packages to avoid fts.h. But as written earlier: that's not so trivial.


> And what about the people using an architecture which is not supported
> by glibc? Like Sparc, ARC, Xtensa and Or1k? Or the no-MMU
> architectures? 
> 
> We enabled Wordexp recently and I would really love to see this
> enabled, too. Could you rethink about your decision?

 wordexp is different because it's actually POSIX. IMO our default uClibc config
should cover all of POSIX.


 Regards,
 Arnout
Thomas Petazzoni July 18, 2017, 9:06 p.m.
Hello,

On Tue, 18 Jul 2017 21:24:05 +0200, Arnout Vandecappelle wrote:

>  I'm with you on this one. If a package can work with uClibc, we really should
> allow it.
> 
>  However, I don't think the solution is to bloat our default uClibc config with
> features that are not useful for 99.82% of our packages. fts.h is not something
> like IPv6 that is useful for a large number of packages.
> 
>  I also don't think we should add more options like BR2_ENABLE_LOCALE that copy
> the uClibc config options.
> 
>  Perhaps the way to go is to have a BR2_TOOLCHAIN_UCLIBC_BLOAT_CONFIG option
> that a user can set to indicate he wants to see packages that will not work with
> our default uClibc config. That option could give a nice warning that this
> configuration is not tested and YMMV.

I have to say I don't like this. If we have an option, it should work,
and therefore be tested. It's the worst thing for users to simply tick
an option, and discover build failures here and there. If you have an
option that explicitly allows to do something, then that something
should work.

Best regards,

Thomas
Waldemar Brodkorb July 18, 2017, 9:07 p.m.
Hi,
Thomas Petazzoni wrote,

> Hello,
> 
> On Tue, 18 Jul 2017 21:24:05 +0200, Arnout Vandecappelle wrote:
> 
> >  I'm with you on this one. If a package can work with uClibc, we really should
> > allow it.
> > 
> >  However, I don't think the solution is to bloat our default uClibc config with
> > features that are not useful for 99.82% of our packages. fts.h is not something
> > like IPv6 that is useful for a large number of packages.
> > 
> >  I also don't think we should add more options like BR2_ENABLE_LOCALE that copy
> > the uClibc config options.
> > 
> >  Perhaps the way to go is to have a BR2_TOOLCHAIN_UCLIBC_BLOAT_CONFIG option
> > that a user can set to indicate he wants to see packages that will not work with
> > our default uClibc config. That option could give a nice warning that this
> > configuration is not tested and YMMV.
> 
> I have to say I don't like this. If we have an option, it should work,
> and therefore be tested. It's the worst thing for users to simply tick
> an option, and discover build failures here and there. If you have an
> option that explicitly allows to do something, then that something
> should work.

I still don't get it.
We are not trying to disable fts in glibc, so it is available there.
Why we can't enable it for uClibc-ng to get more compatibility?
Just because of the bigger size?

If someone needs a really small system, there is always the
possibilty to use a really small uClibc-ng config.

best regards
 Waldemar

Patch hide | download patch | download mbox

diff --git a/package/uclibc/uClibc-ng.config b/package/uclibc/uClibc-ng.config
index 5beb2bd90..3a3a15fa3 100644
--- a/package/uclibc/uClibc-ng.config
+++ b/package/uclibc/uClibc-ng.config
@@ -33,6 +33,7 @@  UCLIBC_HAS_GLIBC_CUSTOM_STREAMS=y
 UCLIBC_HAS_PRINTF_M_SPEC=y
 UCLIBC_HAS_WORDEXP=y
 UCLIBC_HAS_NFTW=y
+UCLIBC_HAS_FTS=y
 UCLIBC_HAS_FTW=y
 UCLIBC_HAS_GNU_GLOB=y
 RUNTIME_PREFIX="/"