uclibc-ng: enable fts in default config file.

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

Hello,

Quoted 1 line · Adam Duskett

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

75 KB, or 5-7 KB ?

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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 <[email protected]>

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 16 lines · Adam Duskett

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.

Quoted 1 line

Signed-off-by Adam Duskett <[email protected]>

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.

Quoted 21 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 17 lines · Adam Duskett

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 <[email protected]>

Quoted 5 lines

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?

--
Bye, Peter Korsgaard

Quoted 2 lines

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?

Hello,

Quoted 5 lines · Peter Korsgaard

Quoted 2 lines

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.

Quoted 11 lines

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

Quoted 3 lines

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
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 5 lines · Peter Korsgaard

Quoted 2 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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.

Quoted 28 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 5 lines · Peter Korsgaard

Quoted 2 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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?

Quoted 8 lines

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"

Hi Peter, Thomas,
Peter Korsgaard wrote,

Quoted 43 lines

Quoted 28 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Hello,

Quoted 5 lines · Peter Korsgaard

Quoted 2 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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?

Quoted 8 lines

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

Quoted 2 lines

Peter Korsgaard wrote,

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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

Hi Peter, Thomas,
Peter Korsgaard wrote,

Quoted 6 lines

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?

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.

Hello,

Quoted 7 lines · Arnout Vandecappelle

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.

Quoted 7 lines

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.

Hi,
Thomas Petazzoni wrote,

Quoted 21 lines

Hello,

Quoted 8 lines · Arnout Vandecappelle

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

Quoted 7 lines

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

Quoted 5 lines

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.

1. As a representative of those minorities who's been living without glibc ? ?I'm a bit disappointed to see those packages that "depends on *GLIBC*" ? ?especially if that's just a matter of config option in some tool.

2. Speaking about bloating of default uClibc config in Buildroot I think ? ?we saw movements from both sides but in the same direction:
? ? - uClibc's options get removed or become enabled by default to make it ? ? ? simpler, cleaner and more robust tool but that inevitable adds a couple ? ? ? of hundred bytes here and there. I haven't done comparison of uClibc ? ? ? sizes from release to release, but might be Waldemar has some data here. ? ? - Buildroot's add-ons to uClibc's defaults also were adding more and more ? ? ? things [and some unconditionally]. For example IPv6 is always on now while ? ? ? I guess this option adds quite a bit of size.

3. Regarding purity of standards I may agree that we as more knowledgeable ? ?engineers need to educate our users and resist temptation to return to ? ?deprecated things. But as an advocate of my users I'd say that usability ? ?and support of wider packages might be even more important.

Quoted 4 lines

3. Regarding purity of standards I may agree that we as more knowledgeable ? ?engineers need to educate our users and resist temptation to return to ? ?deprecated things. But as an advocate of my users I'd say that usability ? ?and support of wider packages might be even more important.

Yes, I agree that there is a balance between "purity" and "pragmatism".

I don't have a very strong opinion on this FTS enabled or not. I don't remember the size measurements with FTS enabled/disabled. Perhaps we should just enable all features needed by Buildroot packages in our uClibc configuration.

Quoted 4 lines

3. Regarding purity of standards I may agree that we as more knowledgeable ? ?engineers need to educate our users and resist temptation to return to ? ?deprecated things. But as an advocate of my users I'd say that usability ? ?and support of wider packages might be even more important.

Yes, I agree that there is a balance between "purity" and "pragmatism".

I don't have a very strong opinion on this FTS enabled or not. I don't remember the size measurements with FTS enabled/disabled. Perhaps we should just enable all features needed by Buildroot packages in our uClibc configuration.

Hi,
Thomas Petazzoni wrote,

Quoted 9 lines

Quoted 6 lines

3. Regarding purity of standards I may agree that we as more knowledgeable ? ?engineers need to educate our users and resist temptation to return to ? ?deprecated things. But as an advocate of my users I'd say that usability ? ?and support of wider packages might be even more important.

Yes, I agree that there is a balance between "purity" and "pragmatism".

Quoted 4 lines

I don't have a very strong opinion on this FTS enabled or not. I don't remember the size measurements with FTS enabled/disabled. Perhaps we should just enable all features needed by Buildroot packages in our uClibc configuration.

That would be indeed the best policy!

And I don't think a lot is missing. May be just FTS!