s390x-musl: define O_LARGEFILE constant

[nekopsykose]

from https://git.musl-libc.org/cgit/musl/tree/arch/s390x/bits/fcntl.h?id=4b125dd408d54487dc8843b9553502aa0c4167f8#n16

it's a nop as noted in 75ac488, but afaik we should still expose the symbol(?)

[rustbot]

r? @JohnTitor

(rustbot has picked a reviewer for you, use r? to override)

[bossmc]

I agree that libc should probably expose the value (so code that checks if it is set in a bitmask works?) but I think it's set to 0x8000 on all linux (64-bit?) architectures so probably can be put in musl/b64/mod.rs (or even in musl/mod.rs, or even even 'linux/mod.rs`?) and have the rest of the definitions removed (see #3261 for other examples of this).

[nekopsykose]

but I think it's set to 0x8000 on all linux (64-bit?) architectures

doesn't seem to be (note aarch64, for instance), from musl source:

arch/x32/bits/fcntl.h
16:#define O_LARGEFILE 0100000
arch/powerpc/bits/fcntl.h
16:#define O_LARGEFILE 0200000
arch/s390x/bits/fcntl.h
16:#define O_LARGEFILE 0100000
arch/powerpc64/bits/fcntl.h
16:#define O_LARGEFILE 0200000
arch/mipsn32/bits/fcntl.h
16:#define O_LARGEFILE 020000
arch/m68k/bits/fcntl.h
16:#define O_LARGEFILE 0400000
arch/generic/bits/fcntl.h
16:#define O_LARGEFILE 0100000
arch/aarch64/bits/fcntl.h
16:#define O_LARGEFILE 0400000
arch/mips64/bits/fcntl.h
16:#define O_LARGEFILE 020000
arch/mips/bits/fcntl.h
16:#define O_LARGEFILE 020000
arch/arm/bits/fcntl.h
16:#define O_LARGEFILE 0400000

(see #3261 for other examples of this).

ok, that seems much more thorough as a unification project. perhaps you'd like to also add these constants into that too? although in this case, these don't actually seem consistent for all 32 or all 64 bit widths..

[nekopsykose]

(so code that checks if it is set in a bitmask works?)

my initial motivation is that rust 1.70 built on s390x musl now fails without this exposed. i'm not exactly sure why, as the failure is from nix which hasn't changed in forever (this constant is checked here )

perhaps because of some doc feature.. but it indeed is harmless to expose, so hotpatching it for vendor/libc worked fine.

[bossmc]

Huh, there's more divergence than I expected, don't worry about the unification then!

[nekopsykose]

no worries, thanks for the review! always nice to see people working on these interfaces too :)

[JohnTitor]

Thanks! @bors r+

[bors]

📌 Commit 4d473b2 has been approved by JohnTitor

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4d473b2 with merge 3b808cf...

[bors]

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 3b808cf to main...