IRC channel logs
2020-11-03.log
back to list of logs
<OriansJ>vagrantc: honestly, I am quite concerned that debian can't build mescc-tools as I have verfied that make clean test works without issue with gcc 10.2.0 and the make file doesn't have any special requirements <OriansJ>it seems to be trying to CD into the kaem directory; which wouldn't work unless your version included fossy's work. Otherwise it would be doing the old build pattern <vagrantc>OriansJ: yes, i reproduced those errors locally ... so some toolchain changes since it was working <vagrantc>that said, applying all the patches from git, and it builds just fine ... so hence my interest in a new release :) <vagrantc>or i can build a heavily patched version, or just make a local git snapshot <OriansJ>vagrantc: the solution is -fcommon in kaem/makefile at the end of CFLAGS <OriansJ>fossy: gcc-10+ treats including a .h as declaring all of the globals multiple times <OriansJ>vagrantc: but it isn't passed to the kaem makefile <vagrantc>in fact, i think i'm the one who reported that workaround :) <OriansJ>The solution is two way: fast: just use -fcommon to get GCC to ignore that and the proper way, which is to create a globals file and change the globals in the .h into externs <vagrantc>ah, the makefile isn't inheriting the CFLAGS <OriansJ>on commit d95036679c53f9ede644b55ad470bbb1c20fcc5b (which the problem can be reproduced) apply that diff and boom make clean test works again <vagrantc>but in debian, gcc 10 has been the default since december... <vagrantc>so, why did it start failing in october? <vagrantc>or couldn't the kaem makefile inherrit the CFLAGS passed? <vagrantc>ah yes, that's what the patch i have does <vagrantc>anyways, thanks for poking at it ... gotta head out <OriansJ>vagrantc: hopefully that fixes your build problem (until we can do a proper release) <OriansJ>Still trying to find time to hack on hex2 to get its speed up prior to the release <vagrantc>OriansJ: that should already work due to debian/patches/* inheriting the -fcommon from debian/rules <OriansJ>plus fossy probably will want to revert my kaem changes (and get it into proper shape) <vagrantc>the git checkout doesn't apply that patch... <vagrantc>e.g. QUILT_PATCHES=debian/patches quilt push --fuzz=0 --all <vagrantc>i guess i can bisect the patch that fixes the build :) *vagrantc is never tried a bisect to find the fix before... <OriansJ>also the makefile has bin instead of | bin and the kaem makefile doesn't appear to be waiting for ../bin either <OriansJ>So if the build system added more cores, the kaem build could complete before bin was created <lfam>I'm still running the VM I used to try reproducing your '?' bug, if you want me to try anything else, or look something up <OriansJ>lfam: that is the thing. If we have (approximately) identicial setups; running the same binaries on the same source code, the behavior *shouldn't* be different but it is; so I am left with the question of why. <OriansJ>So I have no choice but to try to reduce the possible differences further; using gemu and alot of patience.