Description of problem: While building Dave Jones' trinity software, the build died: CC net/proto-rose.o In file included from /usr/include/netrose/rose.h:25:0, from net/proto-rose.c:10: /usr/include/netax25/ax25.h:73:1: error: conflicting types for 'ax25_address' ax25_address; ^~~~~~~~~~~~ In file included from net/proto-rose.c:9:0: /usr/include/linux/ax25.h:47:3: note: previous declaration of 'ax25_address' was here } ax25_address; ^~~~~~~~~~~~ (along with 9 other structures with similar issues. And sure enough, diffing the ax25.h files, the glibc struct ax25_address has "sa_family_t sax25_family;" while the kernel version has "__kernel_sa_family_t sax25_family;" Building with: glibc-headers-2.24.90-19.fc26.x86_64 kernel-headers-4.9.0-0.rc7.git1.1.fc26.x86_64 Version-Release number of selected component (if applicable): glibc-headers-2.24.90-19.fc26.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is the synchronizing headers problem. https://sourceware.org/glibc/wiki/Synchronizing_Headers There is a kernel part and a glibc part that need to be done to ensure the ABI/API is stable depending on the order of inclusion. So we need a kernel bug cloned for this.
(In reply to Carlos O'Donell from comment #1) > This is the synchronizing headers problem. > > https://sourceware.org/glibc/wiki/Synchronizing_Headers > > There is a kernel part and a glibc part that need to be done to ensure the > ABI/API is stable depending on the order of inclusion. I doubt this is needed here because the glibc header is not part of any standard, so we could just include the Linux header (which looks reasonably clean, too) from the glibc header and stop maintaining our own definitions.
(In reply to Florian Weimer from comment #2) > (In reply to Carlos O'Donell from comment #1) > > This is the synchronizing headers problem. > > > > https://sourceware.org/glibc/wiki/Synchronizing_Headers > > > > There is a kernel part and a glibc part that need to be done to ensure the > > ABI/API is stable depending on the order of inclusion. > > I doubt this is needed here because the glibc header is not part of any > standard, so we could just include the Linux header (which looks reasonably > clean, too) from the glibc header and stop maintaining our own definitions. Absolutely. And a review of the header might reveal that.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
We are going to track this upstream here: https://sourceware.org/bugzilla/show_bug.cgi?id=25106 The fix needs to be made upstream in both glibc and linux, then Fedora can inherit that fix.