[klibc] Mips cross-compiling whos

[Olliver Schinagl]

Hey Ben,

On 02-08-2022 21:43, Olliver Schinagl wrote:
> Subject:
> Re: [klibc] Mips cross-compiling whos
> From:
> Olliver Schinagl <oliver at schinagl.nl>
> Date:
> 02-08-2022 21:43
>
> To:
> Ben Hutchings <ben at decadent.org.uk>, klibc at zytor.com
>
>
> 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

Of course you where correct, and of course it now works without 
work-arounds. Btw, alpine does exactly the same with regards to 
installing the headers in the headers package as can be seen here 
https://git.alpinelinux.org/aports/tree/main/linux-headers/APKBUILD#n41.

I do apologize for my ignorance on the header stuff. Thank you for your 
help!

Olliver


>
>> Ben.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zytor.com/archives/klibc/attachments/20220804/974a8604/attachment-0001.htm>