Created attachment 1459733 [details] repro.c Description of problem: $ gcc -c repro.c In file included from repro.c:3: /usr/include/linux/stat.h:56:8: error: redefinition of ‘struct statx_timestamp’ struct statx_timestamp { ^~~~~~~~~~~~~~~ In file included from /usr/include/sys/stat.h:446, from repro.c:2: /usr/include/bits/statx.h:25:8: note: originally defined here struct statx_timestamp ^~~~~~~~~~~~~~~ In file included from repro.c:3: /usr/include/linux/stat.h:99:8: error: redefinition of ‘struct statx’ struct statx { ^~~~~ In file included from /usr/include/sys/stat.h:446, from repro.c:2: /usr/include/bits/statx.h:36:8: note: originally defined here struct statx ^~~~~ Version-Release number of selected component (if applicable): glibc-headers-2.27.9000-40.fc29.x86_64 kernel-headers-4.18.0-0.rc4.git4.1.fc29.x86_64 Can we maybe add a test to the glibc and kernel packages both to check if the header files can be imported, each one separately? It should be a really simple thing to write and would notify about such things like this one, which happen regularly, a bit earlier.
Thanks, these issues really need to go upstream though, it requires fixes in both glibc and the kernel to coordinate header inclusion ordering issues if you want to mix both headers. There really isn't much for downstream Fedora to do except to remind upstream about the issue and work through the most important conflicts. I have planned a sequence of tests for the network headers, but I hadn't looked at stat/statx yet. Are you running into this problem in a real application or this simply something you noticed while testing? I'm trying to understand how likely it is for other developers to run into this and how quickly we should try to coordinate with upstream. I added this to the upstream list of things to fix: https://sourceware.org/glibc/wiki/Synchronizing_Headers I'm marking this CLOSED/WONTFIX. Upstream needs to resolve this. We'll try to push this along, but I won't pull in hacks just to fix this in the Fedora glibc/kernel.
This causes problems with systemd. We nowadays build upstream systemd in Fedora rawhide for CI, so this kind of thing is detected almost immediately and is a problem because unrelated pull requests start failing [1], and it isn't immediately obvious to contributors that Fedora changes are the reason. Normal builds in rawhide fail too of course. [1] https://github.com/systemd/systemd/pull/9593
An older example: `linux/if_tunnel.h` cannot be included on its own: https://github.com/systemd/systemd/blob/master/meson.build#L453. Working around such issues is surprisingly time consuming, because any solution is by definition non-standard and the only way to make sure it doesn't break on a different system is by compiling it everywhere.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > An older example: > `linux/if_tunnel.h` cannot be included on its own: > https://github.com/systemd/systemd/blob/master/meson.build#L453. > > Working around such issues is surprisingly time consuming, because any > solution is by definition non-standard and the only way to make sure it > doesn't break on a different system is by compiling it everywhere. I'm sure that such problems do exist, and that they waste precious developer time. My long-term goal is to fix C++ exception handling to be async-signal-safe (so that we only need one set of functions), and then provide official C++ headers in a separate namespace, written in such a way that do not use the preprocessor. Combined with a way to suppress macro expansion for regions of source code, this will provide a way to reliable way to include both kernel headers and userspace headers without conflicts. For C, I do not see a wayt to solve this. glibc developers do not want to see types like __u64 in glibc headers, and kernel developers do not want to use <stdint.h>. This means that the type definitions will always be subtly different. Such differences seem to make it imprudent to use __has_include to include the kernel header if it is available. And the headers will likely diverge quite substantially soon enough due to the time64_t work.
(In reply to Florian Weimer from comment #4) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > > An older example: > > `linux/if_tunnel.h` cannot be included on its own: > > https://github.com/systemd/systemd/blob/master/meson.build#L453. > > > > Working around such issues is surprisingly time consuming, because any > > solution is by definition non-standard and the only way to make sure it > > doesn't break on a different system is by compiling it everywhere. > > I'm sure that such problems do exist, and that they waste precious developer > time. My long-term goal is to fix C++ exception handling to be > async-signal-safe (so that we only need one set of functions), and then > provide official C++ headers in a separate namespace, written in such a way > that do not use the preprocessor. Combined with a way to suppress macro > expansion for regions of source code, this will provide a way to reliable > way to include both kernel headers and userspace headers without conflicts. > > For C, I do not see a wayt to solve this. glibc developers do not want to > see types like __u64 in glibc headers, and kernel developers do not want to > use <stdint.h>. This means that the type definitions will always be subtly > different. Such differences seem to make it imprudent to use __has_include > to include the kernel header if it is available. And the headers will > likely diverge quite substantially soon enough due to the time64_t work. We solve it by talking, coordinating, and adjusting headers on both sides until they work. That is the only solution I've seen that works reliably.