ia
commented
1 year ago Rate of reproducing this issue locally - about 99%. But sometimes it's slightly different error every next time:
Linking Hexfile/Pinecilv2_multi_compressed_European.elf
lto1: fatal error: bytecode stream in file 'Objects/Pinecilv2/./Core/BSP/Pinecilv2/bl_mcu_sdk/common/partition/partition.o' generated with GCC compiler older than 10.0
compilation terminated.
lto-wrapper: fatal error: riscv-none-elf-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/riscv-none-elf/11.2.0/../../../../riscv-none-elf/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:846: Hexfile/Pinecilv2_multi_compressed_European.elf] Error 1
make[1]: Leaving directory '/build/ironos/source'
make: *** [Makefile:162: firmware-multi_compressed_European] Error 2And it seems my fault after all, sorry! :no_mouth:
TL; DR - probable root cause (mini write-up or today I learned):
- if you call
make -jX target1 target2 ... targetYand you use only oneMakefilethenmaketool using X for parallel build speculatively will try to run needed internal dependencies/internal targets in parallel but every external target from input will be executed one-by-one in order, not in parallel; - BUT if you call
make -jX target1 target2 ... targetYbut inside mainMakefileyou pass through input targets to be executed through another one callmakeof another oneMakefile, then external targets will be run in parallel as well, i.e.makewill just call in parallelmake target1,make target2up untilmake targetX(as much asXs for-j).
I looked through logs before/after changes in push.yml very carefully and noticed that by the way how the logs report building, it seems that in the scenario with cd source && make -j2 multi_... OR in the scenario with make -C source/ (tested locally) option for parallel build -jN if not ignored but applied inside of making every input target in sequential order (one output of Building for Pine64 Pinecilv2 line because make process is the only one).
While after the changes in push.yml targets themselves are run in parallel (two outputs of Building for Pine64 Pinecilv2 line in parallel because make process forked into nproc processes of itself and they started to compile target firmware-multi_compressed_European & target firmware-multi_compressed_Bulgarian+Russian+Serbian+Ukrainian in parallel, hence conflict of binary data in files generated/overwritten leading to compilation error).
Ralim
Describe the bug Multi-lang builds for
Pinecilv2fail withld/lto1errors.To Reproduce
Expected behavior Successful multi-lang builds for
PinecilV2.Details of your device: Build problem, not a device one.
Additional context
I create this issue to:
If you work on your branch in forked repo and see similar problem, please, add comment providing:
Here are the examples of this issue:
lto1 error / upstream:
lto1 error / branch:
ld error / branch:
lto1 error / branch:
At first, I couldn't reproduce it locally, not without
-j$(nproc)at all nor with-j4(since it's the value ofnprocon my system). But when I did put-j2which seems the case with github CI, I got interesting result almost right away:Binary files mentioned in the log above can be found here.
My further plan is to:
-j, with-j2, and with-j4to see the behavior;make:make -C source multi_...vsmake multi_...vscd source && make multi_...(I doubt that this could be the reason but just to exclude the probability that it somehow related to changing build job command for respective build on github CI).My current suspicious that it probably may be somehow related to parallel building creating race condition-like situation (i.e. some binary file is not fully generated yet when some related dependency in a target inside
Makefile"thinks" that it's ready.Less (but not impossible BTW) it could be a bug in the toolchain.