[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#860013: marked as done (linux: libc-compat.h sets __UAPI_DEF_IF_* to 1 even when if.h hasn't been included)

Your message dated Tue, 25 Feb 2025 22:22:30 +0100
with message-id <Z740ll4RGW8ETT8R@eldamar.lan>
and subject line Re: Bug#860013: Bug#824442: <linux/if.h> and <net/if.h> conflict needs to be resolved
has caused the Debian Bug report #860013,
regarding linux: libc-compat.h sets __UAPI_DEF_IF_* to 1 even when if.h hasn't been included
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
860013: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860013
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Source: glibc
Version: 2.22-7
Severity: serious

(Continued from bug #822393.)

glibc's <net/if.h> should check whether <linux/if.h> has already been
included and, if so, avoid making conflicting definitions.

Including the headers in the opposite order works since this change in
Linux 4.6:
https://git.kernel.org/linus/4a91cb61bb995e5571098188092e296192309c77

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
Hi Aurelien,

On Tue, Feb 25, 2025 at 10:15:17PM +0100, Aurelien Jarno wrote:
> 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.

Thanks a lot for your time looking at this older issue and for the
confirmation. I'm closing the bug.

Regards,
Salvatore

--- End Message ---
Reply to: