ninja run in a 32bit chroot on a lage XFS filesystem fails e.g. for MariaDB compilation: -- Configuring done -- Generating done -- Build files have been written to: /var/tmp/portage/dev-db/mariadb-10.4.17/work/mariadb-10.4.17_build >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-db/mariadb-10.4.17/work/mysql ... * Working in BUILD_DIR: "/var/tmp/portage/dev-db/mariadb-10.4.17/work/mariadb-10.4.17_build" ninja -v -j4 -l0 ninja: error: rebuilding 'build.ninja': stat(/usr/share/cmake/Modules/CMakeCCompiler.cmake.in): Value too large for defined data type Reproducible: Always Adding -D_FILE_OFFSET_BITS=64 to CFLAGS while building ninja works around the issue. This should be a blocker for bug #471102.
Upstream doesn't care for more than 6 years now :(
(In reply to Stephan Hartmann from comment #1) > Upstream doesn't care for more than 6 years now :( That's a pity. (looking through the push request mentioned there they seem to be willing to care slightly if the patch only impacts 32bit builds of it) Can we work around it by forcing -D_FILE_OFFSET_BITS=64 via the ebuild? Checking devmanual: https://devmanual.gentoo.org/eclass-reference/flag-o-matic.eclass/index.html flag-o-matic eclass has the helper `append-lfs-flags` for this.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=650171c086d8f52f6dbd008c69529e581e22d18f commit 650171c086d8f52f6dbd008c69529e581e22d18f Author: Stephan Hartmann <sultan@gentoo.org> AuthorDate: 2020-12-20 15:47:27 +0000 Commit: Stephan Hartmann <sultan@gentoo.org> CommitDate: 2020-12-20 15:47:57 +0000 dev-util/ninja: fix LSF handling Closes: https://bugs.gentoo.org/760848 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Stephan Hartmann <sultan@gentoo.org> dev-util/ninja/ninja-1.10.2-r1.ebuild | 136 ++++++++++++++++++++++++++++++++++ 1 file changed, 136 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=102f79613e208193ade66e71ddf6530db3fadc05 commit 102f79613e208193ade66e71ddf6530db3fadc05 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-02-05 23:15:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-05 23:16:32 +0000 dev-build/ninja: fix LFS (by respecting CPPFLAGS) Reported by dilfridge w/ x86 build on XFS (which has larger inodes). See also 280be1cadfdfd607d422dcefa33e9f15bf9c638c. Bug: https://bugs.gentoo.org/760848 Signed-off-by: Sam James <sam@gentoo.org> dev-build/ninja/files/ninja-cppflags.patch | 21 +++++ dev-build/ninja/ninja-1.11.1-r5.ebuild | 118 +++++++++++++++++++++++++++++ dev-build/ninja/ninja-9999.ebuild | 1 + 3 files changed, 140 insertions(+)
the new -r5 ebuild fails for me on native aarch64: ./src/ninja.cc:1402:3: warning: when initialized here [-Wreorder] 1402 | DeferGuessParallelism(BuildConfig* config) | ^~~~~~~~~~~~~~~~~~~~~ aarch64-unknown-linux-gnu-g++ -Lbuild -O2 -pipe -Wl,-O1 -Wl,--as-needed -o ninja build/ninja.o -lninja wrote build.ninja. bootstrap complete. rebuilding... Traceback (most recent call last): File "/var/tmp/portage/dev-build/ninja-1.11.1-r5/work/ninja-1.11.1/configure.py", line 720, in <module> subprocess.check_call(rebuild_args) File "/usr/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['./ninja', '-v']' died with <Signals.SIGSEGV: 11>. the filesystem is plain old ext4, in a chroot on an usb drive via ssh & screen. -r4 is fine, and so is -r5 on my main amd64 machine. should I open a new bug for this and have it depend, or would you like me to add anything of interest here?
new bug please with full build.log, emerge --info, and backtrace from the crash
