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. 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 Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <https://lists.zytor.com/archives/klibc/attachments/20220801/9bd4fc9f/attachment.sig>
On Mon, 2022-08-01 at 20:21 +0200, Ben Hutchings wrote: [...]> 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![...] Actually, the UAPI header guards get rewritten by the kernel's headers_install target so this check is still correct in klibc. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <https://lists.zytor.com/archives/klibc/attachments/20220801/0f01fb1e/attachment.sig>
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#L58In 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. >