Pin tag of musl-cross, tpmtotp and msrtools #618
Conversation
Add `--strip 1` to tar file extraction in the `Makefile`, which ensures that the directory name in `build/` will match the one listed in `$($(MODULE)_dir)`. Signed-off-by: Trammell hudson <[email protected]>
Signed-off-by: Trammell hudson <[email protected]>
Signed-off-by: Trammell hudson <[email protected]>
|
@osresearch : please check #499 |
|
@flammit @osresearch: Not working. Clean redo: Output: |
|
A clean checkout and build on ubuntu-18.04 worked. However, I just noticed that you're getting twp different errors. The first is it looks like the coreboot cross tools failed: The second is that the path to the musl-cross binaries is right, but something is producing weird object files: I'm retrying in docker now. |
|
The checkout and merge command didn't work; I instead just checked out the Digging into the files that are causing the problem, they are ones that are assembled from |
|
@osresearch : even if using ubuntu:18.04 as base docker image. Same pipeline referenced before. No joy. |
|
Looks like the problem is the system's
However, musl-cross is using binutils 2.27, so the If we change |
this should fix issues with compressed ELF header sections.
update musl-cross to 1952975
|
Looks like there is a problem with how I'm unpacking the coreboot blobs. They are being unpacked into |
Signed-off-by: Trammell hudson <[email protected]>
|
Building on the way (fedora-30), have passed where it failed before. |
|
Success on fedora-30 docker-ce: |
|
Building on ubuntu:18.04 clean docker-ce. |
|
Finally fixes the build system. |
|
This breaks the compiler and doesn't resolve anything, really. My local builds (remote GitlabCI build don't even boot, even if builds don't fail) crash dump on lvm binary calls. |
wasn't it the kernel that gets built with musl-cross? |
|
@osresearch @rofl0r @osresearch suggested moving to musl-cross-make here for better portability. Considering pinning musl-cross to latest prior working commit id which otherwise is causing regressions. Heads build system being broken for way too long now :| |
oh. from the report by @osresearch i figured the trouble with binutils was happening while linking the wacky objcopy generated stuff the kernel uses. if musl-cross is used to build a gcc, and that gcc works, it doesn't sound as if it's musl-cross's fault.
yes, and maybe the last known working kernel version. latest is not always necessarily greatest.
when i studied the CI output of this PR, it looked to me like there's at least 3 different x86_64 toolchains built during the process. this is not only inefficient from a build-time/energy consumption point of view, but also rather complex to maintain and pinpoint from where issues are coming from. i suppose it would be advantageous to use a single toolchain for all these steps. |
|
i was refering to coreboot / cross toolchain mentioned in this comment #618 (comment) though upon looking at it again, it seems to be building an arm and an i386 toolchain, plus the musl-cross x86_64 toolchain. there seem to be various gcc and binutils versions involved. so it might be preferable to use only musl-cross-make built for arm and built for i386, both in the same configuration, unless there's a really good reason to use x86_64 over 32 bit x86 binaries somewhere in the process (or x86_64 toolchain with -m32 and -ffree-standing to build bios-level i386 stuff). is there a log of a full build somewhere? the CI reports here in this PR are all cut off due to errors at various stages. |
|
Playing around GitlabCI for a while, but output gets cut off without any reason and resulting artifacts don't work, as opposed to locally built roms in cleanly downloaded docker images, reproducing what is in .gitlabci.yaml file. @rofl0r : Latest successful build, resulting in a artifacts that once flashed brick systems (x230), is here. Building locally with verbose build output. Will comment with full ouput in next comment. |
hmm, this log is quite different. the only toolchain build i've seen is: |
|
@rofl0r :
|
|
your log above seems to be interpreted as markup rather than raw data. but it's identical to the one on gitlab: only an i386 toolchain is built, no mention of musl-cross. did you ever try to build coreboot with an external toolchain (i assume "cross-gcc" is what coreboot builds as part of its own build)? |
|
@rofl0r : Full 42MB output of build here attached, failing in the middle for flaky internet connection and resumed. |
@rofl0r : So something like this is what you would be suggesting? |
it certainly can't hurt if the user can override CC, CFLAGS, etc and use his existing toolchain instead of building it every time from scratch. though the flags' names used there look kinda non-standard, but they're probably modeled after what the build already uses. since the PR doesn't touch anything related to coreboot or musl-gcc, it's not really helping with the amount of toolchains getting built. i wonder whether that's only a CI-thing though or baked into the heads build process. studying the log i noticed that the arm compiler build of coreboot is commented out so that leaves us with an i386 toolchain built for coreboot, and musl-cross x86_64 for the rest. i also noticed that during heads build musl 1.1.15 is getting built, and its musl-gcc wrapper used during build of later packages, instead of the version the cross-compiler targets. anyway, in order to move forward i personally would probably roll back to the last known working commit here (i.e. make a new branch based on that version), then pin the version of musl-cross and the other 2 packages mentioned in the PR title to the version that was used back then. that should bring the project back to a working state, from where each package that's been updated since can be updated in isolation and checked whether that caused the issues. |
These were the only three that were being pulled from git heads rather than specific tags or releases.
Also changes the top level
Makefileextraction of tarballs to use--strip 1, which ensures that the extracted directory matches the name in$($(MODULE)-dir).