Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle API evolution and additions #234

Closed
kamalmarhubi opened this issue Mar 17, 2016 · 6 comments
Closed

Handle API evolution and additions #234

kamalmarhubi opened this issue Mar 17, 2016 · 6 comments

Comments

@kamalmarhubi
Copy link
Contributor

In both #228 and #233, we're having CI failures for constants that aren't present in the headers that the test infrastructure uses.

Possible directions of improvement:

  • verifying constants against the most recent kernel headers instead of whatever headers are installed in CI (suggested by @posborne)
  • switch to generation of constant values instead of verification

With generation, there's still a need to pick the correct type for a constant, so it can't be done purely mechanically. Yay C preprocessor!

@kamalmarhubi
Copy link
Contributor Author

This also relates to #121.

@kamalmarhubi
Copy link
Contributor Author

Relevant: the wiki for predef: Pre-defined Compiler Macros, in particular the Operating Systems and Architectures pages. They list commonly predefined macros for OSes and architectures.

The wiki is also available as an export on GitHub if you prefer.

@alexcrichton
Copy link
Member

I would personally not like to go down the route of generation just yet, but we're free to update whatever headers are on the system at any time in my opinion. They will likely inevitably break existing definitions as binary compatibility is now always upheld, but we can deal with it when it comes.

@kamalmarhubi
Copy link
Contributor Author

@alexcrichton

They will likely inevitably break existing definitions as binary compatibility is now always upheld, but we can deal with it when it comes.

Could you clarify a little what you mean here?

@alexcrichton
Copy link
Member

Ah just that whenever we upgrade the OS image to include a newer glibc in the past something's always broken because some constant changes somewhere.

@gnzlbg
Copy link
Contributor

gnzlbg commented May 24, 2019

For each target_os, currently, libc only supports a very particular OS version. Some OSes preserve backward compatibility, and this works fine there (linux, windows). Others make very minor breaking changes (macos), others make larger breaking changes, but try to preserve ABI compatibility (FreeBSD), and others do not care at all, and each minor OS release is essentially a completely different target (OpenBSD).

How to fix this is being discussed in #570 , so I'm closing this issue. Please feel encouraged to chime up there if you care about this.

@gnzlbg gnzlbg closed this as completed May 24, 2019
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

No branches or pull requests

3 participants