Build Error on building heads: heads/build/coreboot-4.8.1/util/sconfig/sconfig.h:80: multiple definition of `head'; x230-flash/util/sconfig/sconfig.tab.o #853
Comments
|
I know I have seen that error before but can't remember the exact reason. You may be missing a dependency, try this and see if anything needs to be installed. If so, install it and try building again. apt-get install \
bc \
bison \
build-essential \
cpio \
flex \
libelf-dev \
libncurses5-dev \
pkg-config \
texinfo \
zlib1g-dev |
|
Quick reminder that for a Heads commit ID, dependencies for Debian 10 are currently covered under CircleCI under https://github.com/osresearch/heads/blob/master/.circleci/config.yml#L8-L11 as referred under heads-wiki https://github.com/osresearch/heads-wiki/blob/master/Building.md If for some reason, there is corrupted artifacts from past builds (some patches were added for the same module dowloaded version after decompression of module archive), patches are only applied once per module version change. The documentation might need to be clearer on how to create a cleaner build: While you may want to add: And adding this to the precedent commands will rebuild also musl-cross-make: |
Thanks for the quick answer! Will try to do |
Thanks, already installed, but in debian 10 there are some problems with the package python. as i understand, package python is deprecated, so i installed python2 instead and made symlink to python. |
|
unfortunately the same result after |
|
@explit7 this is weird, since CircleCI builds are based on debian-10. Will check again on local QubesOS debian-10 based AppVM on clean build later on |
|
@explit7 @Thrilleratplay [...] |
|
@Thrilleratplay For cache building clarifications on CircleCI:
Then
@Thrilleratplay So unless musl-cross-make git commit changes happened in its module (that module text has changed), that cache is reused. In both caches. I have resetted the cache and also rebuilding from CI, while changing the environment variable in CI which is used here and there which is inserted in build through the But here, at each builds the docker debian:10 container is used, build dependencies and updates are installed, git is cloned and positioned at latest commit, measurements are taken on modules, and the largest cache matching actual modules+patches measurements is reused if key matches on modules measurements. If i'm doing something wrong here please let me know, otherwise, we are not recreating a docker image here, we are trying to simulate a debian-10 compilation but not for a signel board, but for all boards, reusing the caches to save time. |
|
@Thrilleratplay @explit7 clean build following precedent information is happening here You can see:
|
|
thanks. Will also try to fire up ubuntu vm to build it.... if nothing helps |
|
My question is more: what are the differences between docker 10, QubesOS debian-10 Template and native debian-10 installation to cause the issue. As specified under #571, I think its time to move out of trying to build on all OSes of the world, and go docker, where that docker should probably be guix-buildstack as @daym is currently working on, so that end user instructions are clear, implementable in CIs, limiting impacts of host differences and permitting to replicate the results of today's commit in 5 years from now, pulling the same buildstack revision and permitting to fixate toolstack revisions desired for different coreboot versions, for example. |
|
@tlaurion You are not doing anything wrong, the caching is misleading. This means the package versions used in CI are not necessarily the same as those users try to build Heads locally. A package may be updated twice in a month where once version creates an error and a second one does not. The result being intermittent bugs in the build process. A preconfigured docker image with all of the necessary packages installed hosted on a registry, similar to the If this explanation is not clear, please let me know. |
@Thrilleratplay : No! It actually pulls the docker image, calls apt update and then install dependencies at each build. (This is not cached!!!) Please click the links here so that we are all at the same page.
Well. Users should also update their packages and install the dependencies the same way the CI does at each build. I mean. OS is updated, right? On debian-10, this is the only way we have to detect Host releated problems, and why we want to get away of those dependencies.
I do not find the references here but coreboot-sdk is not reproducible right now. (searching source and discussions)
|
|
@tlaurion I looked back through other CircleCI builds and it is updating and installing the packages each build. My apologies. I assumed it would cache this if subsequent layers were also pulling from cache. Yes, users should be able to update their OS but if the goal is reproducible build, changes in package versions would likely result in change to the checksum of the compiled rom. It is not that |
@Thrilleratplay : Glad we finally have a trace of the actual problem we are trying to resolve. :)
And here lies the problem. Theoretically, we would expect host buildstack versions to be sticked to major versions where impact should be limited. Problems lies in having to support really old versions of coreboot now (4.8.1 because #709 and coreboot 4.11 #867) where problems will definitely arise, unless we can switch buildstack prior of building those board in CI or locally per proper instructions against a docker image permitting that, with CI instructions and doc explaining and applying the process.
So maybe solution 1 here is the way to go. While that docker being too recent won't build coreboot 4.8.1 and too old won't build 4.12+. Here lies the problem and hopes into solution 2. |
|
|
Can't replicate :/ |
|
Interestingly enough, that was replicated today for the first time under CircleCI Ubuntu 24.04 docker image (with a lot of patches against coreboot 4.8.1 to try to keep some boards alive) over #1038 Happened against qemu-coreboot CircleCI build |
|
Make that line in sconfig.h:80 state |
|
I put up the change for 4.8_branch at https://review.coreboot.org/c/coreboot/+/58534 |
|
Thanks @pgeorgi |
|
I think those errors linked to buildstack and all others are now solved with #1661 |
Hello colegues.
Have some problems to build heads on Debian 10
Maybe this is known?
Thanks
The text was updated successfully, but these errors were encountered: