|
Bugzilla – Full Text Bug Listing |
| Summary: | gcc14 compilation fails | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Bernhard Wiedemann <bwiedemann> |
| Component: | Other | Assignee: | Richard Biener <rguenther> |
| Status: | REOPENED --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Bernhard Wiedemann
2024-04-21 07:26:31 UTC
Full build log: http://rb.zq1.de/other/gcc14/gcc14-build-log.txt.xz The odd thing is this is behind #ifdef HAVE_WORKING_STAT # define FIND_FILE0_DECL struct stat *st # define FIND_FILE0_ARGS st #else # define FIND_FILE0_DECL uint64_t id, const char *path # define FIND_FILE0_ARGS id, path but yes, if !HAVE_WORKING_STAT the code is broken. So the question would be why !HAVE_WORKING_STAT - we're expecting this only for __MINGW32__. Maybe since this is using -m32 and the test itself isn't built with LFS we fail stat because of a large inode number. Is this failure reproducible? Can you tell me how to reproduce in a local build? I'm second-guessing --define='%do_profiling 0' and maybe -j 1 -t 1 on the osc command-line? Here is a reproducer: osc co openSUSE:Factory/gcc14 && cd $_ osc build --noservice --clean -j1 --disable-debuginfo standard x86_64 failed after 111s on a fast machine. It runs in a 1-core VM, so poorly defined dependencies can cause issues that don't appear in our normal -j4 builds. I just noticed that the lack of --vm-type=kvm makes it run in podman mode with maximum parallelism. (In reply to Bernhard Wiedemann from comment #6) > I just noticed that the lack of --vm-type=kvm makes it run in podman mode > with maximum parallelism. Yep. I can't manage to make --vm-type=kvm work on a SLE15 host, but I edited the spec file to not use -j on the toplevel make. Let's see if that reproduces it. It's the memory-constraints package and %limit_build -m 900 that seems to make the number of jobs larger and not only smaller in some cases. For KVM builds, you need to edit your ~/.config/osc/oscrc to set sufficiently high values (in MB) for build-memory = build-vmdisk-rootsize = Hmm. Now I cannot reproduce the issue on the other machine. Maybe that one build machine creates random errors. Need to test some more... If it ever reproduces can you please preserve the build environment? Found the correct reproducer now: osc build --noservice --vm-type=kvm \ --build-opt=--vm-custom-opt=-rtc\ base=2038-01-20T00:00:00 standard x86_64 while a 2037 build worked fine, so (surpisingly) it is a year-2038 issue. |