tinygo fails to build at Arch Linux clean environment #4332
Comments
Not exactly. The compiler only warns about them: I suspect GCC 14 is just a bit too new for the Binaryen release that we are currently using and they haven't fixed all new warnings yet. So the bug is probably in Binaryen, and a workaround is to use an older compiler. |
|
GCC 14 is the default compiler version at Arch Linux. Does tinygo even expected to be compiled with GCC? What would be a proper solution in case if we want to use the system compiler (GCC 14). |
|
Binaryen most certainly works with GCC, because that's how it is usually compiled in TinyGo. In fact you can see here how I just did it (on Fedora 40): So it looks like this is a problem on Arch Linux specifically. |
|
Hi @aykevl thank you for your reply. I built So the problem is most likely comes from the way the build environment set up. Among other things it sets compilation flags. I compiled Actually it seems that the real error is that is probably cause by one of the security fortification flags. Does the compiler error look legit? |
So the special build environment you have sets those flags and now it fails? I would suggest you report a binaryen bug instead, because this is a problem in the special way that you are building binaryen and it seems to be flagging a bug in binaryen. |
|
There is a rabbit hole for this issue. It seems that GCC has some false positives for the binaryen code . Binaryen enables I disabled It makes sense to add |
|
It also makes sense to setup a github action to compile the binaryen project against different OS. This will expose the project to different compilers/tools and let's catch this type of compatibility problems. Here is an example how it is done for android-tools project https://github.com/nmeum/android-tools/blob/master/.github/workflows/build.yml |
|
That patch to disable failing on errors is a good idea, can you make a PR out of it?
That would not actually have helped in this case because it only fails in a very specific case with custom flags set (not just on any Arch Linux install). I'm also not convinced it's necessary to be spending the CI time on building binaryen across OSes for very specific issues - we already build binaryen on all OSes that we support. (Sidenote: I find it somewhat amusing that a "clean" chroot sets some custom build flags). |
Compilers like GCC keep adding new checks that produce new warnings. Sometimes it can be false positives. Do not treat such warnings in binaryen library as errors. tinygo won't be able to provide zero warnings in its dependencies. Closes tinygo-org#4332
Compilers like GCC keep adding new checks that produce new warnings. Sometimes it can be false positives. Do not treat such warnings in binaryen library as errors. tinygo won't be able to provide zero warnings in its dependencies. Closes tinygo-org#4332
The purpose of the chroot is to provide a hermetic build environment with predictable dependencies/settings/flags. "clean" here really means the chroot does not contain user-specific package installed and does not have any users envvars. All dependencies/flags are declared and are the same no matter who performs the build. This idea is at the core of reproducible builds. |
Compilers like GCC keep adding new checks that produce new warnings. Sometimes it can be false positives. Do not treat such warnings in binaryen library as errors. tinygo won't be able to provide zero warnings in its dependencies. Closes #4332
|
Yeah I didn't realize at first this was a package build. It makes sense for distributions to customize the build environment to the distribution preferences (which includes a certain set of build flags). |
deadprogram
added
bug
I am building this project in a Arch Linux clean environment (kinda chroot with sanitized environment) and the build fails:
The
binaryensubmodule fails to compileSimplifyLocals.cppbecause compile complains about unknown options.The error comes from the fact that the default compiler was picked up, and in the chroot environment that compiler is
/usr/bin/c++that is currently GCC 14.1.1.binaryenon the other hand does not work with GCC. It looks like it expects to be compiled withclang. In this caseGNUmakefileshould reflect it. Setting properCMAKE_CXX_COMPILERcmake variable should help here I think.The text was updated successfully, but these errors were encountered: