Docker build fails at zlib-ng

[tux-linux]

I'm building NickelTC on native armv8 (Raspberry Pi) for armv7 to be able to compile Kobo kernels when on vacation/traveling with a lightweight workstation. So far, I jumped through a few hoops for Qt and koxtoolchain, but I wanted NickelTC for kernels, since it worked in the past for me and you know how Kobos are finicky with this...
I ran docker build . after cloning the repo, Crosstool-NG went fine, but then the buildscript failed at zlib-ng. IIRC, this happened in the Trigger build commit you made 1st of April:

* Building zlib-ng . . .

+ git clone --depth 1 https://github.com/zlib-ng/zlib-ng.git
Cloning into 'zlib-ng'...
+ cd zlib-ng
+ update_title_info
+ pkgName=zlib-ng
+ myPanelTitle='X-TC NICKEL'
+ echo -e '\033kX-TC' 'NICKEL\033\\'
+ myWindowTitle='Building zlib-ng for NICKEL'
+ echo -e '\033]2;Building' zlib-ng for 'NICKEL\007'
+ prune_la_files
+ '[' -d /tc/x-tools/arm-nickel-linux-gnueabihf/arm-nickel-linux-gnueabihf/sysroot/usr/lib ']'
X-TC NICKEL

+ find /tc/x-tools/arm-nickel-linux-gnueabihf/arm-nickel-linux-gnueabihf/sysroot/usr/lib -name '*.la' -type l -delete
+ find /tc/x-tools/arm-nickel-linux-gnueabihf/arm-nickel-linux-gnueabihf/sysroot/usr/lib -name '*.la' -type f -delete
+ patch -p1
patching file arch/arm/armfeature.c
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/armfeature.c.rej
The command '/bin/sh -c cd /tc/sysroot-src && ./kobo-nickel-sysroot.sh' returned a non-zero code: 1

I think the file has changed since last time you created a patch for it, because you're cloning the upstream repo and not a specific commit.
It's my very first time with Docker, I'm not particularly liking it but if you have any suggestions to fix this, it would be appreciated :D

[NiLuJe]

@pgaskin mentioned something to that effect a few weeks/months ago. I've updated the script on my end, but I haven't rebuilt zlib-ng in a bit either, so it may need a refresh again.

I can afford to deal with this in my scripts because I know I'll ultimately fix it once I actually need to run them again, but the Docker script definitely ought to be pinning zlib-ng to a known-good commit ;).

[tux-linux]

It doesn't, since the triggered GH Actions build in April didn't work either...
Or something in the patch needs a fix, on the other hand.
But BTW, is koxtoolchain able to compile kernels, say 4.1.15? 2.6.35.3 won't work (missing compiler header file), but it might be possible for newer devices, don't know if you've tried that?

[NiLuJe]

The kernel buildsystem has a compiler detection mechanism, which means that in practice, old kernels won't recognize new GCC, and havoc ensues. Since NickelTC/the nickel koxtoolchain target build GCC 4.9, that's old enough to deal with that for all the kernels we care about.

TL;DR: Don't build kernels with GCC 11, no ;). All the https://github.com/NiLuJe/mxc_epdc_fb_damage modules shipped in https://github.com/NiLuJe/NanoClock were built with the nickel target (gcc 4.9) for that reason, while everything else is built via the kobo target (gcc 11).

[NiLuJe]

When I said "the script", I meant mine, not the NickelTC Docker tooling.

(Which, again, I haven't re-run in over a year).

[NiLuJe]

Re-reading your original post, if you just want to build kernels, simply build the nickel target in koxtoolchain, you don't need NickelTC and/or the nickel sysroot for that.

[tux-linux]

I wasn't intending to build with GCC 11 at all...
When I saw the "Update to GCC 11" commit, I asked myself if you were not becoming a bit crazy ;p (no offense)
It probably is OK for some userspace, but after encountering random Qt build errors, I decided to revert back to GCC 7.5.0, from an older commit. All seems to work fine, and I'm able to compile InkBox on my Raspberry Pi (not for Qt Creator, because "-m32" flag is not recognized, and that's a whole another story).

For your second message: OK, I didn't see that, thanks
For your third message: Is there a way to keep the default build there for Qt5 then?

[NiLuJe]

GCC 11 is for "new" stuff, not NickelTC, that has to be pinned to 4.9 by design.

I've had no issues w/ GCC11, and, in fact, I think UMR & the custom Qt5 QPA are now built with GCC 11, too.

[NiLuJe]

For your third message: Is there a way to keep the default build there for Qt5 then?

Not quite sure I follow. But that's essentially what my script does: start from the nickel target, then x-build the nickel sysroot with it, and then merge the two together and make Qt5 relocatable for ease of use.

EDIT: Well, the actual relocation & merge scripts are archived in the experiments repo, I haven't touched them in over a year, so YMMV.

I keep forgetting to import them with the rest in SVN, but, again delayed until I actually need to rebuild it.

[tux-linux]

Unless @Rain92 found a fix for this, I encountered numerous build errors saying expected template-name before < token that weren't there in GCC 7.

[NiLuJe]

Unless you're actually building old Qt versions, that's odd. (Remember, Gentoo: we've been building Qt w/ bleeding edge TCs since the dawn of time ;)).

[tux-linux]

Unless you're actually building old Qt versions, that's odd. (Remember, Gentoo: we've been building Qt w/ bleeding edge TCs since the dawn of time ;)).

Yep, IIRC it was namely in stack16.h or something like that. It can't really be an architecture-specific error, can it? I don't have a clue.
But talk to me about it; last week, I did a world update and lost login ability because somehow that update deleted libcrypt and did not put it back ;D

[NiLuJe]

You should have read the eselect news first ;).

[tux-linux]

Oh, I did; I'm on ~amd64. Apparently, nothing should have gone wrong, but something did anyway. I updated 16th of July, so pretty early in the shift.

[pgaskin]

I haven't pulled NiLuJe's updated scripts yet. The GH actions build worked until zlib-ng (which I forgot to pin) got updated. If you want the raw toolchain, just export the latest docker image and extract the nickeltc dir.