Enable large file support on 32-bit Linux

[geri1701]

On 32-bit Linux, stat() in the 0.28.x branch can return EOVERFLOW when an inode number exceeds UINT32_MAX. FileIo::size() converts that error to SIZE_MAX, which causes misleading mmap() ENOMEM and std::vector::max_size() failures.

This defines _FILE_OFFSET_BITS=64 for 32-bit Linux in both CMake and Meson builds. main also uses fseeko() and ftello(), so it benefits from 64-bit file offsets. The patch applies unchanged to 0.28.x.

Verification:

• main: all 6 CTest suites pass serially on i686 and x86_64
• 0.28.9: all 5 CTest suites pass on i686 and x86_64
• Meson unit tests pass on both branches and architectures
• The i686 high-inode reproducer maps the correct 526-byte file instead of requesting 4,294,967,295 bytes

[kevinbackhouse]

32-bit Linux is obsolete, so I don't think it's a good idea to add extra complexity to our build system to support it. I'd prefer to improve the error handling in the code.

Is this the code that's causing the problem?

exiv2/src/basicio.cpp

Lines 205 to 211 in dc9364b

	try {
	buf.st_size = fs::file_size(file);
	buf.st_mode = fs::status(file).permissions();
	return 0;
	} catch (const fs::filesystem_error&) {
	return -1;
	}

We should probably let that exception go up to the main function and exit with an error message.

[geri1701]

Thanks. We’ll keep _FILE_OFFSET_BITS=64 downstream in nixpkgs, where it now passes on the affected machine. I’ll close this PR. Clearer error handling would be a separate improvement.

[kevinbackhouse]

@geri1701: Is this a real issue for nixpkgs? I'm sorry, I just assumed that this was one of those issues that was found by AI and doesn't actually impact anyone in practice. I think we can consider this if it's a genuine issue for nixpkgs. Please could you share a link to the issue where that's being discussed?

[geri1701]

Is this a real issue for nixpkgs?

Yes, it affected Exiv2’s tests in a sandboxed i686 package build, not during normal use: https://redirect.github.com/NixOS/nixpkgs/pull/538986