[klibc] Mips cross-compiling whos

[Olliver Schinagl]

On 01-08-2022 20:21, Ben Hutchings wrote:
> On Tue, 2022-07-26 at 22:30 +0200, Olliver Schinagl wrote:
>> Hey list,
>>
>> I'm trying to cross-compile klibc on mips. As I packaged it for alpine
>> before, I figured it shouldn't be that hard ;) Sadly, alpine doesn't
>> support mips[32|64] so I have to cross-compile it.
> Cross-compilation should work, and I regularly test this for all the
> architectures that Debian provides cross-compilers for.
>
>> I'm doing this from within an alpine based docker container, using a
>> simple script (setup vars, unzip, make).
>>
>>
>> There's a few things I don't understand why they are the way they are,
>> but have a somewhat easy work-around (haven't spend time to figure out
>> if it is the correct one at all or not :p).
>>
>>
>> First, this work-around I have also in the alpine packages, since it's
>> just shuffling stuff around, but keeping all definitions, I don't
>> mind/care much.
>>
>> ```
>>
>>           if [ ! -e 'usr/include/sys/sysinfo.h.orig' ]; then
>>               mv 'usr/include/sys/sysinfo.h' \
>>                  'usr/include/sys/sysinfo.h.orig'
>>           fi
>>           cat \
>>               '/usr/include/linux/sysinfo.h' \
>>               'usr/include/sys/sysinfo.h.orig' > \
>>               'usr/include/sys/sysinfo.h'
>> ```
> This doesn't make any sense to me.  Our sys/sysinfo.h already includes
> <linux/kernel.h>, which includes <linux/sysinfo.h>.
>
>> excuse the uglyness :p
>>
>>
>> Secondly, specificaly on mips, I get re-definition errors, I haven't
>> looked into detail why `f_owner_ex` is redefined, but I use the
>> following here:
>>
>> ```
>>
>>           sed -i \
>>               -e '/^typedef struct flock {$/i # define
>> HAVE_ARCH_STRUCT_FLOCK/' \
>>               -e '/^struct f_owner_ex {$/,+6d' \
>>               'usr/include/arch/mips/klibc/archfcntl.h'
>>
>> ```
> It's also defined in <asm/fcntl.h>, which I think is "wrong" on MIPS.
> We try to prevent including both <klibc/archfcntl.h> and <asm/fcntl.h>,
> though it looks like that check broke about 10 years ago in the UAPI
> split!
>
>> Lastly, _KLIBC_USE_RT_SIG supposedly 'can' be used on mips, but it
>> causes a `-1` unnamed array definition error, so 'can' means 'does not
>> needed to be', so I just disabled it.
>>
>>
>> ```
>>
>>           sed -i 's|^\(#define _KLIBC_USE_RT_SIG \).*$|\1 0|'
>> 'usr/include/arch/mips/klibc/archconfig.h'
>>
>> ```
> This is not a configuration option.  You can't change it without
> changing the architecture implementation too.
>
> [...]
>> Now, to compile, I use
>>
>> ```
>>
>>           make \
>>                KBUILD_REPRODUCIBLE=1 \
>>                KLIBCARCH="mips" \
>>                KLIBCKERNELSRC='/usr/' \
>>                ;
>>
>> ```
> [...]
>
> This causes klibc to use the kernel headers for the build machine's
> architecture, which is wrong for cross-builds.  This is probably the
> source of all or most of the errors.

Ah hah! That explains a lot then.


So for arm, I didn't have much of a problem; but I did use the 'general 
amd64' linux-headers. I wasn't aware that linux-headers was a 'per 
target' specific package. I know I can easily of course install the 
target's header package.

>
> If you have a working cross-compiler then it must have a copy of the
> kernel headers for the target architecture installed somewhere, and you
> need to tell klibc where that is or link to it.  I don't know how
> Alpine packages cross-tools, but this is what we do in Debian:
> https://salsa.debian.org/kernel-team/klibc/-/blob/master/debian/rules#L58

In alpine, you run/install everything 'nativily' usually. E.g. the 
linux-headers package gets created once per arch, on supported arches. 
There is no mips32 support on alpine; so I can't "just install 
linux-headers" from mips; which means I'll figure out (what debian does) 
to get the appropiate headers. Probably means I have to fix my alpine 
builds as well, which probably is the trigger of my (only) workaround 
with the sysconf.h stuff.


I'll fix this stuff and will get back to you. Sorry for my 
headers-ignorance :p

>
> Ben.
>