-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update testsuite compilers and OSs for Jammy #5415
Conversation
… g++12 wants this anyway)
g++12 Debug builds work now. g++12 Release builds fail with various warnings from included system headers ( |
I do not get these errors with gcc 12.1.0 (CI uses 12.0.1). Instead I get two errors which I only could resolve by using local GCC_DIAG_OFF, but then it compiled (both debug and release):
and
|
Using Ubuntu 22.04 and g++12.0.1 in a docker container, here's the err output. I think it matches what the CI is doing (build stops at 76%). I'm configuring with
I don't see any references to atomic_base.h but I do for std_function.h. Seems to be most related to the warnings about using variables that may be uninitialized. This may be a situation where using fanalyzer might be useful to help track down why the variables may be uninitialized |
Here's the output when fanalyzer is used: |
When I tried on Arch in a docker container, using 12.1.0, the release build fails at 76% |
I know my knowledge of cpp is limited, but I've not a clue as to why when I initialize
|
If it makes you feel any better, I just added a test for gcc-12 on Jammy for one of my small projects. I've had the fanalyzer flag enabled for a while and it's been clean. With 12, not so much. https://github.com/theimpossibleastronaut/rmw/runs/6443383022?check_suite_focus=true#step:3:239 |
After reviewing the new warnings for my own project, I've concluded they're false positives. So I disabled them in theimpossibleastronaut/rmw@998a405 @Noordfrees As long as widelands is checking with clang and other versions of g++, it would probably be safe to do the same for the warnings about possible use of uninitialized values, using a condition to check if the compiler is gcc && version 12 or greater. And then try enabling the warnings again when gcc-12.2.0 is released. |
Looks like that can be done by adding a pragma to a header but in this example would affect all versions of gcc https://stackoverflow.com/questions/29320555/how-to-disable-wmaybe-uninitialized-warning |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor stuff I suggested really. Seems like @Noordfrees has this all under control. LGTM!
libsdl2-ttf-dev\ | ||
python3\ | ||
zlib1g-dev \ | ||
${ADD_PKG_LIST} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${ADD_PKG_LIST} | |
${ADD_PKG_LIST} | |
exit 0 |
Good practice to include an exit statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't do this in any other script, and it doesn't add any value IMHO since it's implicit
@@ -177,7 +177,7 @@ void do_log(const LogType type, const Time& gametime, const char* const fmt, ... | |||
assert(logger != nullptr); | |||
|
|||
// message type and timestamp | |||
char buffer_prefix[32]; | |||
char buffer_prefix[256]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
char buffer_prefix[256]; | |
char buffer_prefix[sizeof "[24:00:00.000 xxxx] XXXXXXX:"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to change the format in the future, even for something small, then we'd need to update two places instead of one. It's just one stack-allocated array with short lifespan so this doesn't have any impact resources-wise; also the gametime can have 3 or more digits in the hour in which case this could overflow. So IMHO better to allow some extra space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok for now. Let's have it, so everyone can compile again.
This compiler is known to cause false-positive warnings.
Do you know of already reported similar issues? Is this something the compiler devs are already aware of?
Thanks for the review :) The GCC C++ bug tracker lists several recent regressions around warnings as well as several reports about spurious warnings in v12 so this seems to be a known (and common) problem. |
Can we get a new release with this? Widelands doesn't currently compile in Arch because of this and the patch doesn't apply cleanly. |
I'm not sure what you need. The current development version does compile fine (there is also an PKGBUILD for it in the AUR). The last release (1.0) is provided as prebuilt package for many platforms and should not be needed to be compiled. If you still want to compile it, simply install and use gcc11 package. |
Distributions don't usually use prebuilt binaries if it can at all be helped. We like to compile things from source so that we can be sure the all binaries are using the same binary hardening, for instance. Also in Arch Linux, we don't really have a way to go back to old compilers usually. As such, I'd still appreciate a new release. Otherwise if that is not possible, I could look into building a recent commit and shipping that but I'd rather not if it can be helped. |
We're already in feature freeze for the v1.1 release. There are still some open PRs and issues targeted to v1.1 that need testing and review. I expect the release to happen in late summer or early autumn this year. What exactly is the problem when building v1.0 with latest compilers? Would patching the CMakeLists.txt to remove the |
Yeah that'd work and that's what I would have gone with anyway in case you couldn't get a release out short term. We try not to mess with upstream compile options if it can be helped. :) |
No description provided.