Skip to content

Conversation

@illwieckz
Copy link
Member

Properly detect Linux with glibc to detect what's not, no need to list everything else.

It makes it easier to build for something else we currently don't support, either being another operating system, or Linux with another libc.

I yet again faced the problem of assuming Glibc on Linux when toying with Fil-C that uses musl by default. I do remember having faced similar problems in the past with other stuff. Android? Zig? I don't remember precisely, but I knew that code was fragile, maybe it's better this way.

I'm curious to see if the CI will be happy or not.

If that works, then adding new operating systems would even require less code, not needing to list every of them.

@slipher
Copy link
Member

slipher commented Nov 15, 2025

  • native_client: properly detect Linux with glibc to detect what's not LGTM
  • FileSystem: properly detect Linux with glibc to detect what's not seems dubious. The *64 family of functions/structs is apparently defined in POSIX; I get hits for various commercial Unices, including MacOS since 10.5. So I don't see the motivation to associate it with glibc.
  • FileSystem: let Native Client do open() like others hard to say since it appears to depend on the previous commit.

@illwieckz
Copy link
Member Author

I merged the first commit.

@illwieckz
Copy link
Member Author

illwieckz commented Nov 26, 2025

  • FileSystem: properly detect Linux with glibc to detect what's not seems dubious. The *64 family of functions/structs is apparently defined in POSIX; I get hits for various commercial Unices, including MacOS since 10.5. So I don't see the motivation to associate it with glibc.

Possibly, but that doesn't prevent us to cleanup the code. We were already avoiding the *64 family outside of Linux, so that code changes nothing for other unices like macOS, etc. What this patch does is to avoid the *64 family on Linux when glibc isn't there.

In the future we can add more tests to enable *64 functions on more systems.

@illwieckz
Copy link
Member Author

I tested macOS and open64 and others don't exist. Actually we may avoid open64() on Linux.

@illwieckz
Copy link
Member Author

It looks like we don't need open64(), as glibc remaps open() as open64() and other symbols when _FILE_OFFSET_BITS 64 is set. Other libc (like musl) may only provide a 64-bit large file implementation anyway.

@illwieckz
Copy link
Member Author

The macOS manpage mentions things like fstat64() but as deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants