[Buildroot] [PATCH 1/1] Add BR2_TOOLCHAIN_HAS_FTS config option

[Adam Duskett]

Hello;

On Thu, Jul 6, 2017 at 11:37 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Hello,
>
> On Thu,  6 Jul 2017 11:23:45 -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.
>>
>> This patch does the following:
>>
>> - Create a BR2_TOOLCHAIN_HAS_FTS configuration option in uclibc/Config.in
>>   and automatically set the kconfig during the configure stage.
>> - when glibc is selected, BR2_TOOLCHAIN_HAS_FTS is now selected.
>>
>> This will allow for packages that require glibc only because of fts.h to now
>> depend on BR2_TOOLCHAIN_HAS_FTS instead of BR2_TOOLCHAIN_USES_GLIBC.
>>
>> Signed-off-by: Adam Duskett <aduskett at codeblue.com>
>
> What is the size impact of enabling FTS by default in uClibc-ng ?
>
Around 7.5Kb.  This might not be a bad way to go.

> Adding such an option is more complicated. Here you're doing it for the
> internal toolchain backend. But then the external toolchain backend
> would need the same option, and check whether the toolchain really has
> FTS support, etc. It's not that simple to add new options for uClibc,
> so we try to avoid doing that.
>
> What about instead migrating the SELinux stuff away from the BSD-style
> fts() interface to the POSIX compliant nftw() interface ?
>
> It would IMO make a lot more sense.
>
I read your post on the mailing list, and I took a look at the libselinux code.
It would not be trivial. Over 150 references, several functions would have to
be completely rewritten, etc etc.

It seems like the SELinux developers are against doing it themselves, and I
don't have the time to learn how to port fts reliant code to nftw, nor test it,
and then submit an upstream patch. I would love to, but time is not on my
side these days.

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

Thanks!
Adam