Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #86142

Bug#860013: Bug#824442: <linux/if.h> and <net/if.h> conflict needs to be resolved

Cross-posted to 2 groups.

Show all headers | View raw

Hi,

On 2025-02-22 21:13, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Tue, Apr 11, 2017 at 11:28:41PM +0100, Ben Hutchings wrote:
> > Control: severity -1 important
> > Control: severity 824442 important
> > 
> > On Tue, 2017-04-11 at 23:20 +0200, Aurelien Jarno wrote:
> > > On 2017-04-11 03:35, Ben Hutchings wrote:
> > > > Control: tag -1 moreinfo
> > > > 
> > > > On Mon, 10 Apr 2017 10:48:45 +0200 Aurelien Jarno <aurelien@aurel32.net> wrote:
> > > > [...] 
> > > > > Unfortunately I have been pointed on the libc-alpha mailing list that
> > > > > it doesn't work if another file which includes <linux/libc-compat.h>
> > > > > (e.g. <linux/xattr.h>) is included before <net/if.h>. The problem is
> > > > > that the __UAPI_DEF_IF_* constants are set to 1 in <linux/libc-compat.h>
> > > > > even if <linux/if.h> is not included.
> > > > 
> > > > [...]
> > > > 
> > > > Does this affect any real programs, or is this just theoretical (and
> > > > therefore should be downgraded)?
> > > 
> > > It depends what do you mean by real program. I doubt it still affect
> > > debian packages. The change has been introduced by kernel 4.5, and I
> > > guess by now all the FTBFS have been fixed. At least for stretch, they
> > > might be a few left in sid.
> > 
> > While the fix in the kernel is clearly incomplete, I think it must have
> > worked for most programs.
> > 
> > > Now some of the fixes might not have reached upstream yet.
> > > 
> > > If we consider that acceptable, we can lower the severity of the bugs on
> > > both the kernel and the glibc side.
> > 
> > Let's do that.
> 
> I see there were back in history two commits which had fixes for
> 4a91cb61bb99 ("uapi glibc compat: fix compile errors when glibc
> net/if.h included before linux/if.h") .
> 
> Is there still something which needs to be done on either side (glibc,
> kernel) or should we close this issue?

I have just tested it, and the issue is still reproducible with:

  #include <linux/xattr.h>
  #include <net/if.h>
  #include <linux/if.h>

That said in practice this strange order is not used so it doesn't seems
to cause any problem for building packages.

I believe that the remaining fix is on the glibc side, there have been
some attempts [1]|2], but they never converged. As this is tracked by
#824442 on the glibc side, I believe that #860013 on the kernel side can
be closed.

Regards
Aurelien

[1] https://sourceware.org/legacy-ml/libc-alpha/2017-04/msg00154.html
[2] https://sourceware.org/legacy-ml/libc-alpha/2018-04/msg00067.html

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Bug#860013: Bug#824442: <linux/if.h> and <net/if.h> conflict needs to be resolved Salvatore Bonaccorso <carnil@debian.org> - 2025-02-22 21:20 +0100
  Bug#860013: Bug#824442: <linux/if.h> and <net/if.h> conflict needs to be resolved Aurelien Jarno <aurel32@debian.org> - 2025-02-25 22:20 +0100

csiph-web