Re: [liblo] [ann] liblo 0.27 released

On Tue, Jul 9, 2013 at 7:45 AM, Stephen Sinclair <rad...@gm...> wrote:

> I indeed missed the change to lo_server_recv_raw_stream() from the
> ABI, it's an oversight and I take responsibility, but perhaps it's
> more something I'm misunderstanding than a real oversight; I still
> don't get why an *internal* function being removed would cause a
> problem.

I found about this change by a semi-automated tool that scans the
exported symbols in a shared library. From the POV of that tool, all
exported symbols are public.

> For the record, I did check binary compatibility using the
> "icheck" utility, but usage of this tool requires passing in the
> header files.  Since lo_server_recv_raw_stream() does not appear in
> the header files, it was not reported as problematic.

If a function is exported in the library but is not in the headers,
then for someone to use it they would need to actively work against
what the library intended. I say they get what they ask for when the
function is removed.

That said:

>
> Although I guess I should have not made this function static, it
> should not have been in the public ABI in the first place.  That said,
> sometimes in C there are internal functions that do get exposed to the
> ABI just because they need to be shared between modules.  (An example
> is lo_address_resolve(), which is in one case called from send.c)
>
> If anyone knows good practice to avoid this kind of issue please let me know.

Yes, as long as all functions remain in the same shared library (eg,
send.c ends up in liblo, not in a test program, which seems to be the
case).
In linux, by default all symbols are exported in a shared library. In
windows, it is the opposite (don't know about mac, but it is likely
like linux). This is the reason liblo already includes a .def file to
export the public symbols in windows. In linux, gcc can be told to
behave in a similar way to windows (although more powerful, as it also
allows versioning). Short version of such a version map:

{
    global:
        lo_address_errno;
        lo_address_errstr;
        // etc etc
    local:
        *;
};

This would mark all functions not explicitly listed in the global
scope as local to the shared library, and thus unavailable for client
applications.

If versioning is desired, a more complex symbol map is required. More
info on this is in the DSO howto by Ulrich Drepper

http://www.akkadia.org/drepper/dsohowto.pdf


>
>
>> - members of this list, please try to give more feedback and be more reactive when a release date is coming.  It does not cost a lot to spend 15 minutes getting the latest code and running the tests.
>
> Additionally, if anyone knows good resources to test things let me
> know.  One problem is that at the moment "testlo" is a bit of a mess.
> But even the unit testing can't catch all the problems.  One
> suggestion to me was to check reverse dependencies in debian to find
> what programs depend on liblo, and test them all.  But I'm afraid that
> doing this, particularly on multiple architectures and operating
> systems, is a bit more work than I can manage to put in.  I have no
> choice but to depend on the community for testing, and I can't fix
> what isn't reported.

I could enable the test suite in debian, I didn't realize there was
one. This should give at least some free testing. However, the
testsuite seems to run forever, is it that long or is there a bug?
Currently it seems to have deadlocked:
./test_bidirectional_tcp
0xce0008.server fd: 3
0xce0008.receiving1..
0xce0ee8.sending thread
0xce0008.done receiving1
0xce0008.receiving2..
0xce0008./test, from TCP::
0xce0008.address fd: -1
0xce0ee8.message sent
0xce0ee8.sending thread waiting
0xce0008.reply sent
0xce0008.done receiving2


And it hangs there.

--

Saludos,
Felipe Sateler