[Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[buildroot at athaariq.my.id]

Hello Mr. Morrin,

> This issue is really weird, because the glibc commit we are using is
> supposed to contain the related fixes

Pardon me for being so weird. What I'm trying to fix is this error:

```
/builds/buildroot.org/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/linux/mount.h:92:6: 
error: multiple definition of ‘enum fsconfig_command’
    92 | enum fsconfig_command {
       |      ^~~~~~~~~~~~~~~~
In file included from 
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:62:
/builds/buildroot.org/buildroot/output/build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:249:6: 
note: previous definition here
   249 | enum fsconfig_command
       |      ^~~~~~~~~~~~~~~~
```

I did spent entire morning last two days ago and I figured out that no 
matter how do I detect linux/mount.h presence in "sys/mount.h", **enum 
fsconfig_command** still in clash between linux-headers and glibc. 
However, the problem only exist in glibc v2.36 whereas no effect when I 
changed linux version. Thus, linux-headers seems to be declared after 
glibc.

> How is this a buildroot-specific bug? Can you elaborate on that part? 
> If
> it is really a buildroot-related bug, then we want to understand it, 
> and
> fix it, not work around it.

Because it successfully compiled in Gentoo but failed when compile 
Buildroot for Raspberry Pi 4 and Raspberry Pi 3, with default 
configuration. The reason why I asked "Is this possible on Buildroot?" 
is to give you two options:
1. If possible, let's make sure linux-headers installed before glibc
2. If not, let's workaround for a while until there's a revelation from 
upstream

> This is exactly what we are doing already, and for as long as Buildroot
> has supported building a glibc-ased toolchain, as the kernel headers 
> are
> required to build glibc; see package/glibc/glibc.mk at 28:

Well that's interesting. Wonder why that enum redeclaration error exist 
and my last patch actually works.

> To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
> 2.36 commit, and even one older than ours, but they do not seem to have
> issues.

Honestly, I only tested it on my Raspberry Pi 4 and my friend's 
Raspberry Pi 3 with latest origin/master and default configuration. 
Yesterday, I realized that all raspberry boards are symlinked into one 
directory after checked autobuild. Perhaps, board specific issue? If 
correct, I'm going to patch the custom kernel instead, plus bump it.

I also noticed Raspberry Pi boards are marked ORPH at autobuild. Is that 
means orphan? If yes, I would gladly contribute as board maintainer. 
Thank you for your cooperation.

Regards,
Athaariq Ardhiansyah

NB: My nickname is Eric