On 11/7/19 8:23 AM, Florian Weimer wrote: > Officially, it's supposed to work today. We have one glibc developer > who says that it's easy to solve, but I disagree strongly. The fact > that the problems are not fixed promptly suggests that it's anything but > simple. Is that one glibc developer me? :-) They aren't easy to solve, but there is a magic process in place. Getting the definitions to line up is part of the work involved. Sometimes they may not line up, in that case it doesn't work. > What I've been doing instead is to include UAPI headers directly from > glibc headers if it's technically feasible. (It's not possible in POSIX > mode, where we have to manage the set of exported symbols closely, or > generally with old compilers which do not have __has_include.) See > <bits/statx.h>, <bits/statx-generic.h> etc. in current glibc for an > example. That's really the best way to solve it if you can. > If you add more type definitions to kernel headers, this might interfere > with such usage of UAPI headers because today, we need to provide our > own definitions for many things not in UAPI headers, and the currently > deployed glibc headers are simply not compatible with such future > changes. Right. -- Cheers, Carlos.
