Re: suggested fix
On 20/06/12 12:27, Steven Chamberlain wrote:
> On 20/06/12 11:56, Nicholas Bamber wrote:
>> I have a proposed fix as attached. It's built, signed and ready to go.
>> If you have intentions to fix it yourself please reply and do so
>> promptly. I'll run my fix past a few people for feedback but after that
>> I'll upload with a 2-day delay.
>
> Thanks for this. It looks okay and seems it would fix the FTBFS.
>
> However... I'm wondering if a more generic test could be used instead of
> FreeBSD || FreeBSD_kernel. Other BSD's would need this header too for
> the sockaddr_dl definition[1]. And it looks like GNU/Hurd was failing
> on this same code so it possibly has (or should have) the same.
>
> [1] http://fxr.watson.org/fxr/trackident?v=FREEBSD9;i=sockaddr_dl
> [2]
> https://buildd.debian.org/status/fetch.php?pkg=pmacct&arch=hurd-i386&ver=0.14.0-1&stamp=1339115492
>
> What about using AF_LINK as a test of whether to include this header?
> It looks to me like it would work.
>
> This way we'd be helping out GNU/Hurd at the same time, the fix would be
> more appropriate for upstream and it helps with future portability.
>
> Thanks again,
> Regards,
Steven,
Sorry I didn't notice the FTBS on hurd as I was concentrating on the
red. I guess I should have trusted the bug report title more.
However I am confused at what your are proposing. For a start I cannot
find a net/if_dl.h file on Hurd. Secondly I am not clear if using
AF_LINK as a conditional is a good idea. Surely that would change the
code on Linux, which is surely not what we want to do. Also googling for
Hurd and sockaddr_dl has not so far turned up anything useful. What
bugs such as #636510 and #256669 do suggest is that AF_LINK is a bad
indicator of the presence of sockaddr_dl. Maybe the solution is to
furher guard the #ifdef AF_LINK bits by requiring that the OS not be Hurd.
Reply to: