Re: [liblo] [ANN] liblo version 0.28 released

On Tue, Feb 4, 2014 at 1:59 PM, Felipe Sateler <fsa...@gm...> wrote:
> On Tue, Feb 4, 2014 at 4:42 AM, Stephen Sinclair <rad...@gm...> wrote:
>> Hi Felipe,
>>
>> Hm, that is unexpected.  Since it is already #ifdef'd out, why is it
>> causing a problem?  I'm not sure I understand the mechanism behind the
>> build network.  Is it being built on an old kernel, but against
>> headers for a newer kernel?  That's the only reason I could think this
>> would cause a problem..
>
> Indeed, that is the problem, as already mentioned by IOhannes.
> The buildd network consists of machines
> running debian stable (that is, a 3.2 kernel) in which a chroot with
> debian unstable is created. The package is built in the chroot, so
> that means we have new libc and kernel headers, but old runtime
> kernel. As mentioned in the original mail, the problem is during the
> testsuite run, not at build time.

Sure -- I was proposing running a program at configure time to detect
if it is available, but you're right it may be better to do it every
time the code runs.  This implies (as I state below) simply trying to
set it but ignoring any error, but this just feels a bit weird to me.

>> That said, perhaps it would actually be better to detect the existence
>> of SO_REUSEPORT at configure time instead of compile time, not sure if
>> that would fix the problem or not.
>
> It wouldn't really fix it, because the fundamental problem is that
> kernel features can only be detected at runtime, because there is no
> guarantee that the running kernel is the same as the one with which
> the package was built. It would make it easier to disable it, though.
>
> Maybe on lo_server_new a test could be made to check if SO_REUSEPORT
> is supported by the kernel (AFAICT SO_REUSEPORT is only used on the
> server?).

That's not a bad idea...

> I'm a bit confused as to how lo_throw works, but that seems to be the
> proximate cause of the problem. Alternative solution: perhaps liblo
> can just ignore the setsockopts(SO_REUSEPORT) errors?

I think ignoring the error is the correct behaviour in conditions
where it is not needed anyway, but then perhaps it shouldn't be
attempted in the first place.  The goal is to not have unpredictable
behaviour, unicast and multicast should "just work" under all
supported operating systems.  I have to go back through old emails,
but if I remember it turned out that SO_REUSEPORT was needed on OS X,
and available but not actually needed on Linux.

>> Yes, technically you could just take out those sections of the code,
>> but I was hoping you wouldn't need to repack the archive.  I don't
>> understand why SO_REUSEPORT is defined if it is not supported.
>
> Ok, I'm commenting out the code section to prevent build failures for
> now. If SO_REUSEPORT can be detected at runtime or the errors can be
> safely ignored, I can replace the patch with one that does the right
> thing.

I think patching the code for Linux is an ok solution for now, but I'd
like to figure out the right thing to do.  I would have been happy
taking the flag out entirely as IOhannes has suggested in the past,
but I ran into some situation which needed it, and made the assumption
that if it is defined, it should be required.


Steve