liblo-devel Mailing List for LibLO

On Fri, Nov 29, 2013 at 3:44 PM, Felipe Sateler <fsa...@gm...> wrote:

> On Fri, Nov 29, 2013 at 10:52 AM, Stephen Sinclair <rad...@gm...>
> wrote:
> > On Fri, Nov 29, 2013 at 2:09 PM, Felipe Sateler <fsa...@gm...>
> wrote:
> >>
> >> On Sat, Nov 9, 2013 at 10:01 AM, Stephen Sinclair <rad...@gm...>
> >> wrote:
> >> > Hi Felipe,
> >> >
> >> > On Fri, Nov 8, 2013 at 4:52 AM, Felipe Sateler <fsa...@gm...>
> >> > wrote:
> >> >> OK I think I know where the real problem is now. I've modified
> >> >> test_deserialise as follows:
> >> >>
> >> >>     printf("%i\n", sizeof(lo_arg));
> >> >>     printf("%p\n", argv[0]);
> >> >>     printf("%p\n", argv[1]);
> >> >>     printf("%p\n", argv[2]);
> >> >>     printf("%p\n", argv[3]);
> >> >>     printf("%p\n", argv[4]);
> >> >>     printf("%p\n", argv[5]);
> >> >>     printf("%p\n", argv[6]);
> >> >>
> >> >> Right after argv is assigned. And this is what I get:
> >> >>
> >> >> 8
> >> >> 0x30e98
> >> >> 0x30e9c
> >> >> 0x30ea0
> >> >> 0x30ea4
> >> >> 0x30eb0
> >> >> 0x30eb4
> >> >> 0x30ebc
> >> >>
> >> >> So lo_arg is 8 bytes wide. However, note that some are less than 8
> >> >> bytes apart. This causes problems on sparc, because (luckily) the
> >> >> first 8 byte message is not 8-byte aligned, but 4-byte aligned.
> >> >>
> >> >> The reason seems to be (from my relatively cursory look at the code)
> >> >> because liblo keeps message data in one large array, which it then
> >> >> offsets according to each data type length.
> >> >
> >> > Right, this seems to be fairly integral to how liblo is designed.
> >> > Without being able to test myself (and I have thus far been
> >> > unsuccessful in getting a SPARC emulator running), I don't see how we
> >> > can easily make progress on this issue.
> >>
> >> A discussion today on a debian IRC channel pointed me to the following
> >> page[1], which has a list of archs that allow unaligned access. Those
> >> that don't are:
> >>
> >> alpha, armel, hppa, ia64, mips, mipsel, sparc, sh4
> >>
> >> I would think that armel and mipsel are the only interesting ones for
> >> liblo (ie, tablets, phones, or other smallish hardware). It was
> >> pointed out that some (but not all, like sparc) allow unaligned access
> >> via a software trap (ie, the kernel traps the error, does a manual
> >> fetch of all the pieces and gives you what you requested in the first
> >> place). This fetch is of course much more expensive than the single
> >> load requested. Which means that if the read operations are
> >> performance sensitive, the unaligned access is highly suboptimal.
> >> Google also says that even in the case when the architecture allows
> >> unaligned access, it might be slower than an aligned access (but I
> >> haven't found a definitive source for this).
> >>
> >> All this suggests that maybe it is worthwhile to fix the issue even if
> >> nobody uses sparc.
> >>
> >> Arm linux systems have a file /proc/cpu/alignment that can be used to
> >> set what happens when an unaligned access happens[2]. The attached
> >> test program generates a sigbus on my (raspbian) raspberry pi, but
> >> strangely enough the oscdump + oscend combination described earlier
> >> does not cause a SIGBUS (perhaps arm alignment requirements are less
> >> strict than sparcs).
> >
> >
> >
> > I think it should be possible to fix this.  It implies that for some
> > architectures the OSC memory needs to be copied and re-aligned before
> > passing argv arguments to message handlers.  I'm not sure without a bit
> more
> > research whether this extra memory handling would be compatible with
> liblo's
> > current API semantics.  If not, we could keep it in mind when working on
> a
> > new major version.
>
> But we don't know which architectures have the alignment issues :(. It
> seems that sparc is the only one that actually dies on a 8-byte access
> at a 4-byte alignment. People keep telling me it is slower (even when
> allowed), but I haven't been able to find a reference for that.
>

Detecting it at configure time using a crashing program is likely possible,
but for slowness it's obviously harder to detect.  I'd be fine with simply
providing it as a manual option in this case.


> It seems to me that the non-API-breaking solution would be to 8-byte
> align the array that stores the data, and if the previous packing is
> required during transfer, then pack it at transfer time, and de-pack
> at receive time.
>

Yes, that is possibly a way to do it, but my inclination is that it would
be worth skipping these operations on architectures where it's not
necessary.



> Did you "echo 5 > /proc/cpu/alignment"? Perhaps arm only requires
> 4byte alignment.
>

Just tried it... couldn't get any bus errors using oscsend / oscdump.
test_bidirectional_tcp worked fine.

With both 0 and 5 for /proc/cpu/alignment, I get the following error with
testlo:

./testlo
passed 0 == lo_message_get_argc(msg)
*** Error in `./testlo': realloc(): invalid next size: 0x00024730 ***

I'll have to get gdb running on there to help debug this.

Steve

On Fri, Nov 29, 2013 at 10:52 AM, Stephen Sinclair <rad...@gm...> wrote:
> On Fri, Nov 29, 2013 at 2:09 PM, Felipe Sateler <fsa...@gm...> wrote:
>>
>> On Sat, Nov 9, 2013 at 10:01 AM, Stephen Sinclair <rad...@gm...>
>> wrote:
>> > Hi Felipe,
>> >
>> > On Fri, Nov 8, 2013 at 4:52 AM, Felipe Sateler <fsa...@gm...>
>> > wrote:
>> >> OK I think I know where the real problem is now. I've modified
>> >> test_deserialise as follows:
>> >>
>> >>     printf("%i\n", sizeof(lo_arg));
>> >>     printf("%p\n", argv[0]);
>> >>     printf("%p\n", argv[1]);
>> >>     printf("%p\n", argv[2]);
>> >>     printf("%p\n", argv[3]);
>> >>     printf("%p\n", argv[4]);
>> >>     printf("%p\n", argv[5]);
>> >>     printf("%p\n", argv[6]);
>> >>
>> >> Right after argv is assigned. And this is what I get:
>> >>
>> >> 8
>> >> 0x30e98
>> >> 0x30e9c
>> >> 0x30ea0
>> >> 0x30ea4
>> >> 0x30eb0
>> >> 0x30eb4
>> >> 0x30ebc
>> >>
>> >> So lo_arg is 8 bytes wide. However, note that some are less than 8
>> >> bytes apart. This causes problems on sparc, because (luckily) the
>> >> first 8 byte message is not 8-byte aligned, but 4-byte aligned.
>> >>
>> >> The reason seems to be (from my relatively cursory look at the code)
>> >> because liblo keeps message data in one large array, which it then
>> >> offsets according to each data type length.
>> >
>> > Right, this seems to be fairly integral to how liblo is designed.
>> > Without being able to test myself (and I have thus far been
>> > unsuccessful in getting a SPARC emulator running), I don't see how we
>> > can easily make progress on this issue.
>>
>> A discussion today on a debian IRC channel pointed me to the following
>> page[1], which has a list of archs that allow unaligned access. Those
>> that don't are:
>>
>> alpha, armel, hppa, ia64, mips, mipsel, sparc, sh4
>>
>> I would think that armel and mipsel are the only interesting ones for
>> liblo (ie, tablets, phones, or other smallish hardware). It was
>> pointed out that some (but not all, like sparc) allow unaligned access
>> via a software trap (ie, the kernel traps the error, does a manual
>> fetch of all the pieces and gives you what you requested in the first
>> place). This fetch is of course much more expensive than the single
>> load requested. Which means that if the read operations are
>> performance sensitive, the unaligned access is highly suboptimal.
>> Google also says that even in the case when the architecture allows
>> unaligned access, it might be slower than an aligned access (but I
>> haven't found a definitive source for this).
>>
>> All this suggests that maybe it is worthwhile to fix the issue even if
>> nobody uses sparc.
>>
>> Arm linux systems have a file /proc/cpu/alignment that can be used to
>> set what happens when an unaligned access happens[2]. The attached
>> test program generates a sigbus on my (raspbian) raspberry pi, but
>> strangely enough the oscdump + oscend combination described earlier
>> does not cause a SIGBUS (perhaps arm alignment requirements are less
>> strict than sparcs).
>
>
>
> I think it should be possible to fix this.  It implies that for some
> architectures the OSC memory needs to be copied and re-aligned before
> passing argv arguments to message handlers.  I'm not sure without a bit more
> research whether this extra memory handling would be compatible with liblo's
> current API semantics.  If not, we could keep it in mind when working on a
> new major version.

But we don't know which architectures have the alignment issues :(. It
seems that sparc is the only one that actually dies on a 8-byte access
at a 4-byte alignment. People keep telling me it is slower (even when
allowed), but I haven't been able to find a reference for that.

It seems to me that the non-API-breaking solution would be to 8-byte
align the array that stores the data, and if the previous packing is
required during transfer, then pack it at transfer time, and de-pack
at receive time.

>
> I recently tested oscsend and oscdump on a BeagleBone and it seemed to have
> no issues. (Although multicast would not work over the Debian 'tun' device I
> was using to communicate with it.)

Did you "echo 5 > /proc/cpu/alignment"? Perhaps arm only requires
4byte alignment.




-- 

Saludos,
Felipe Sateler

On Fri, Nov 29, 2013 at 2:09 PM, Felipe Sateler <fsa...@gm...> wrote:

> On Sat, Nov 9, 2013 at 10:01 AM, Stephen Sinclair <rad...@gm...>
> wrote:
> > Hi Felipe,
> >
> > On Fri, Nov 8, 2013 at 4:52 AM, Felipe Sateler <fsa...@gm...>
> wrote:
> >> OK I think I know where the real problem is now. I've modified
> >> test_deserialise as follows:
> >>
> >>     printf("%i\n", sizeof(lo_arg));
> >>     printf("%p\n", argv[0]);
> >>     printf("%p\n", argv[1]);
> >>     printf("%p\n", argv[2]);
> >>     printf("%p\n", argv[3]);
> >>     printf("%p\n", argv[4]);
> >>     printf("%p\n", argv[5]);
> >>     printf("%p\n", argv[6]);
> >>
> >> Right after argv is assigned. And this is what I get:
> >>
> >> 8
> >> 0x30e98
> >> 0x30e9c
> >> 0x30ea0
> >> 0x30ea4
> >> 0x30eb0
> >> 0x30eb4
> >> 0x30ebc
> >>
> >> So lo_arg is 8 bytes wide. However, note that some are less than 8
> >> bytes apart. This causes problems on sparc, because (luckily) the
> >> first 8 byte message is not 8-byte aligned, but 4-byte aligned.
> >>
> >> The reason seems to be (from my relatively cursory look at the code)
> >> because liblo keeps message data in one large array, which it then
> >> offsets according to each data type length.
> >
> > Right, this seems to be fairly integral to how liblo is designed.
> > Without being able to test myself (and I have thus far been
> > unsuccessful in getting a SPARC emulator running), I don't see how we
> > can easily make progress on this issue.
>
> A discussion today on a debian IRC channel pointed me to the following
> page[1], which has a list of archs that allow unaligned access. Those
> that don't are:
>
> alpha, armel, hppa, ia64, mips, mipsel, sparc, sh4
>
> I would think that armel and mipsel are the only interesting ones for
> liblo (ie, tablets, phones, or other smallish hardware). It was
> pointed out that some (but not all, like sparc) allow unaligned access
> via a software trap (ie, the kernel traps the error, does a manual
> fetch of all the pieces and gives you what you requested in the first
> place). This fetch is of course much more expensive than the single
> load requested. Which means that if the read operations are
> performance sensitive, the unaligned access is highly suboptimal.
> Google also says that even in the case when the architecture allows
> unaligned access, it might be slower than an aligned access (but I
> haven't found a definitive source for this).
>
> All this suggests that maybe it is worthwhile to fix the issue even if
> nobody uses sparc.
>
> Arm linux systems have a file /proc/cpu/alignment that can be used to
> set what happens when an unaligned access happens[2]. The attached
> test program generates a sigbus on my (raspbian) raspberry pi, but
> strangely enough the oscdump + oscend combination described earlier
> does not cause a SIGBUS (perhaps arm alignment requirements are less
> strict than sparcs).
>


I think it should be possible to fix this.  It implies that for some
architectures the OSC memory needs to be copied and re-aligned before
passing argv arguments to message handlers.  I'm not sure without a bit
more research whether this extra memory handling would be compatible with
liblo's current API semantics.  If not, we could keep it in mind when
working on a new major version.

I recently tested oscsend and oscdump on a BeagleBone and it seemed to have
no issues. (Although multicast would not work over the Debian 'tun' device
I was using to communicate with it.)

Steve

On Sat, Nov 9, 2013 at 10:01 AM, Stephen Sinclair <rad...@gm...> wrote:
> Hi Felipe,
>
> On Fri, Nov 8, 2013 at 4:52 AM, Felipe Sateler <fsa...@gm...> wrote:
>> OK I think I know where the real problem is now. I've modified
>> test_deserialise as follows:
>>
>>     printf("%i\n", sizeof(lo_arg));
>>     printf("%p\n", argv[0]);
>>     printf("%p\n", argv[1]);
>>     printf("%p\n", argv[2]);
>>     printf("%p\n", argv[3]);
>>     printf("%p\n", argv[4]);
>>     printf("%p\n", argv[5]);
>>     printf("%p\n", argv[6]);
>>
>> Right after argv is assigned. And this is what I get:
>>
>> 8
>> 0x30e98
>> 0x30e9c
>> 0x30ea0
>> 0x30ea4
>> 0x30eb0
>> 0x30eb4
>> 0x30ebc
>>
>> So lo_arg is 8 bytes wide. However, note that some are less than 8
>> bytes apart. This causes problems on sparc, because (luckily) the
>> first 8 byte message is not 8-byte aligned, but 4-byte aligned.
>>
>> The reason seems to be (from my relatively cursory look at the code)
>> because liblo keeps message data in one large array, which it then
>> offsets according to each data type length.
>
> Right, this seems to be fairly integral to how liblo is designed.
> Without being able to test myself (and I have thus far been
> unsuccessful in getting a SPARC emulator running), I don't see how we
> can easily make progress on this issue.

A discussion today on a debian IRC channel pointed me to the following
page[1], which has a list of archs that allow unaligned access. Those
that don't are:

alpha, armel, hppa, ia64, mips, mipsel, sparc, sh4

I would think that armel and mipsel are the only interesting ones for
liblo (ie, tablets, phones, or other smallish hardware). It was
pointed out that some (but not all, like sparc) allow unaligned access
via a software trap (ie, the kernel traps the error, does a manual
fetch of all the pieces and gives you what you requested in the first
place). This fetch is of course much more expensive than the single
load requested. Which means that if the read operations are
performance sensitive, the unaligned access is highly suboptimal.
Google also says that even in the case when the architecture allows
unaligned access, it might be slower than an aligned access (but I
haven't found a definitive source for this).

All this suggests that maybe it is worthwhile to fix the issue even if
nobody uses sparc.

Arm linux systems have a file /proc/cpu/alignment that can be used to
set what happens when an unaligned access happens[2]. The attached
test program generates a sigbus on my (raspbian) raspberry pi, but
strangely enough the oscdump + oscend combination described earlier
does not cause a SIGBUS (perhaps arm alignment requirements are less
strict than sparcs).


[1] https://wiki.debian.org/ArchitectureSpecificsMemo
[2] http://stackoverflow.com/questions/16548059/how-to-trap-unaligned-memory-access

-- 

Saludos,
Felipe Sateler

Alright Steve, sounds fine!
It's true that the cpp wrapper is just a header thus impacting the API only.


> On 28 nov. 2013, at 16:07, Stephen Sinclair <rad...@gm...> wrote:
> 
> On Wed, Nov 27, 2013 at 3:17 PM, Camille Troillard
> <ca...@os...> wrote:
>> 
>>> On 27 nov. 2013, at 15:01, Stephen Sinclair <rad...@gm...> wrote:
>>> 
>>> I pushed a proposed change to a github branch called "struct_types":
>>> 
>>> https://github.com/radarsat1/liblo/tree/struct_types
>>> 
>>> I think this is a positive change, but it could have implications for
>>> user code since technically it is an API change, although I believe it
>>> does not change the ABI.
>> 
>> I believe the same.
>> 
>> 
>>> I'm of two minds on whether to merge this.
>> 
>> Here is a suggestion:
>> 
>> I think we should focus on making the C code as free of bugs as possible.
>> 
>> Changing the type definitions will help go towards that goal, but it is risky to publish this change without making it well advertised to the users.
>> 
>> The new C++ wrapper helped identify an important weakness, but it is IMHO a bit too young to be distributed at this moment.
>> 
>> What about removing the C++ wrapper for this release (0.28) and extend the testing period with an RC2 release?
>> 
>> Then, we can peacefully think about the next release that includes the C++ wrapper and the better type definitions.
> 
> I will think about a way to get the C++ wrapper to work with
> ServerThread, or perhaps just remove ServerThread from it until it can
> be made safe.  However, I'd like to include the C++ wrapper in the
> release because I think it will never get enough testing without
> including it.  It should be safe to include because 1) no previous
> code could be using it since it is new, and 2) it is a header-only
> wrapper and therefore has no effect on the ABI.  I want to encourage
> people to use it early so that any API-breaking changes that are
> needed, if any, can be included in a new major-version of liblo.
> 
> That said, I'm fairly convinced that it is pretty safe, I have
> extensively tested it, including ensuring that memory is correctly
> tracked and freed.
> 
> As for changing the type definitions in lo_types.h, I will definitely
> not include this in 0.28, as it will certainly break existing code.  I
> have been compiling some reverse dependencies of liblo in Ubuntu and
> seeing errors in several packages.  Mainly (unfortunately) due to
> copy-pasting of the handler definitions in example_server.c where
> void* is used in place of lo_message.  (I'll change these.)
> 
> Probably it's time to start collecting API-breaking changes in a 1.0 fork.
> 
> In the meantime I'll keep testing against existing code that uses
> liblo.  (and binaries)
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Wed, Nov 27, 2013 at 3:17 PM, Camille Troillard
<ca...@os...> wrote:
>
>> On 27 nov. 2013, at 15:01, Stephen Sinclair <rad...@gm...> wrote:
>>
>> I pushed a proposed change to a github branch called "struct_types":
>>
>> https://github.com/radarsat1/liblo/tree/struct_types
>>
>> I think this is a positive change, but it could have implications for
>> user code since technically it is an API change, although I believe it
>> does not change the ABI.
>
> I believe the same.
>
>
>> I'm of two minds on whether to merge this.
>
> Here is a suggestion:
>
> I think we should focus on making the C code as free of bugs as possible.
>
> Changing the type definitions will help go towards that goal, but it is risky to publish this change without making it well advertised to the users.
>
> The new C++ wrapper helped identify an important weakness, but it is IMHO a bit too young to be distributed at this moment.
>
> What about removing the C++ wrapper for this release (0.28) and extend the testing period with an RC2 release?
>
> Then, we can peacefully think about the next release that includes the C++ wrapper and the better type definitions.

I will think about a way to get the C++ wrapper to work with
ServerThread, or perhaps just remove ServerThread from it until it can
be made safe.  However, I'd like to include the C++ wrapper in the
release because I think it will never get enough testing without
including it.  It should be safe to include because 1) no previous
code could be using it since it is new, and 2) it is a header-only
wrapper and therefore has no effect on the ABI.  I want to encourage
people to use it early so that any API-breaking changes that are
needed, if any, can be included in a new major-version of liblo.

That said, I'm fairly convinced that it is pretty safe, I have
extensively tested it, including ensuring that memory is correctly
tracked and freed.

As for changing the type definitions in lo_types.h, I will definitely
not include this in 0.28, as it will certainly break existing code.  I
have been compiling some reverse dependencies of liblo in Ubuntu and
seeing errors in several packages.  Mainly (unfortunately) due to
copy-pasting of the handler definitions in example_server.c where
void* is used in place of lo_message.  (I'll change these.)

Probably it's time to start collecting API-breaking changes in a 1.0 fork.

In the meantime I'll keep testing against existing code that uses
liblo.  (and binaries)

Steve

> On 27 nov. 2013, at 15:01, Stephen Sinclair <rad...@gm...> wrote:
> 
> I pushed a proposed change to a github branch called "struct_types":
> 
> https://github.com/radarsat1/liblo/tree/struct_types
> 
> I think this is a positive change, but it could have implications for
> user code since technically it is an API change, although I believe it
> does not change the ABI.

I believe the same. 


> I'm of two minds on whether to merge this.

Here is a suggestion:

I think we should focus on making the C code as free of bugs as possible.

Changing the type definitions will help go towards that goal, but it is risky to publish this change without making it well advertised to the users.

The new C++ wrapper helped identify an important weakness, but it is IMHO a bit too young to be distributed at this moment. 

What about removing the C++ wrapper for this release (0.28) and extend the testing period with an RC2 release?

Then, we can peacefully think about the next release that includes the C++ wrapper and the better type definitions.

Best,
Cam

Thanks Steve!

Is there something we can use to test the ABI? I think I've heard you mentioning a tool for this.

I'm sorry I can't give you a definite answer about the implications of redefining the opaque pointers. I have always compiled liblo sources right into my application and never bothered using it as a dynamic library.

Cam

> On 27 nov. 2013, at 14:20, Stephen Sinclair <rad...@gm...> wrote:
> 
>> On Wed, Nov 27, 2013 at 2:05 PM, Stephen Sinclair <rad...@gm...> wrote:
>> There could be ways to fix this using typedef'd structs instead of
>> void pointers or something like that... I'm not sure whether such a
>> change wouldn't have pretty bad implications for the API though.  I'll
>> look into it.
> 
> I'll just note that I'm experimenting with changing the typedefs in
> lo_types.h from void* to struct{}*, and it's exposing a bunch more
> similar mistakes.
> 
> I've always found the argument ordering in lo_send_message_from() to
> be confusing. :(
> 
> For some reason I always expect these functions to be called
> lo_message_send() and lo_message_send_from(), and take a lo_message as
> first argument.. I get it wrong almost every time.  We should
> definitely try to get the compiler to flag these kind of mistakes, (if
> it's possible without breaking everyone's code.)
> 
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Wed, Nov 27, 2013 at 2:20 PM, Stephen Sinclair <rad...@gm...> wrote:
> On Wed, Nov 27, 2013 at 2:05 PM, Stephen Sinclair <rad...@gm...> wrote:
>> There could be ways to fix this using typedef'd structs instead of
>> void pointers or something like that... I'm not sure whether such a
>> change wouldn't have pretty bad implications for the API though.  I'll
>> look into it.
>
> I'll just note that I'm experimenting with changing the typedefs in
> lo_types.h from void* to struct{}*, and it's exposing a bunch more
> similar mistakes.
>
> I've always found the argument ordering in lo_send_message_from() to
> be confusing. :(
>
> For some reason I always expect these functions to be called
> lo_message_send() and lo_message_send_from(), and take a lo_message as
> first argument.. I get it wrong almost every time.  We should
> definitely try to get the compiler to flag these kind of mistakes, (if
> it's possible without breaking everyone's code.)

I pushed a proposed change to a github branch called "struct_types":

https://github.com/radarsat1/liblo/tree/struct_types

I think this is a positive change, but it could have implications for
user code since technically it is an API change, although I believe it
does not change the ABI.

I'm of two minds on whether to merge this.  Pros:

- It better-ensures correct API usage.
- It provides enough information that it fixes the bad implicit cast
bug for lo::ServerThread in cpp_test.c.

Cons:

- Current user code that sloppily uses void* in place of some types
will now fail to compile.  This includes some of the liblo examples!

Not sure whether to push it or not.. perhaps the bug fixes could be
pushed in 0.28 and API changes left to the next version.  (Perhaps
it's time to think about bumping the major version.)

On the other hand I hesitate to leave the implicit cast problem in the
C++ wrapper, although that is totally new code and shouldn't affect
existing code bases.

Steve

On Wed, Nov 27, 2013 at 2:05 PM, Stephen Sinclair <rad...@gm...> wrote:
> There could be ways to fix this using typedef'd structs instead of
> void pointers or something like that... I'm not sure whether such a
> change wouldn't have pretty bad implications for the API though.  I'll
> look into it.

I'll just note that I'm experimenting with changing the typedefs in
lo_types.h from void* to struct{}*, and it's exposing a bunch more
similar mistakes.

I've always found the argument ordering in lo_send_message_from() to
be confusing. :(

For some reason I always expect these functions to be called
lo_message_send() and lo_message_send_from(), and take a lo_message as
first argument.. I get it wrong almost every time.  We should
definitely try to get the compiler to flag these kind of mistakes, (if
it's possible without breaking everyone's code.)


Steve

On Tue, Nov 26, 2013 at 5:51 PM, Camille Troillard
<ca...@os...> wrote:
> Hi Steve,
>
> A little story ...
>
> When running cpp_test built for i386.
> If I comment the cpp_test.cpp:152, no error occurs.
>
>     a.send_from(st, "test1", "i", 20);
>
> More precisely, the same happens if lo_cpp.h:138 is commented:
>
>     int r = lo_send_message_from(from, address, path, m);
>
>
> Running cpp_test in lldb shows that the error occurs when lo_server_free is called:
>
> frame #4: 0x0007eede liblo.7.dylib`lo_server_free(s=0x0014f720) + 350 at server.c:726
>    723              s->ai = NULL;
>    724          }
>    725          if (s->hostname) {
> -> 726              free(s->hostname);
>    727              s->hostname = NULL;
>    728          }
>    729          if (s->path) {
>
> At this point s->hostname == 0x9
>
> I stepped around the call at lo_cpp.h:138 and found that the hostname field of the lo_server was as expected “” (empty string) before the call as expected, then became 0x1 when entered in the body of lo_send_message_from!
>
> Still stepping, at send.c:541, I can see “a->errnum = geterror()“ where a is a lo_address and errnum == 0x9.  It became clear that there was a problem in the function call.  Going back to lo_cpp.h showed that lo_send_message_from was called with the first two arguments swapped.
>
> “That was easy”, but took me two hours!  How can we avoid that?  I believe for some reason the warnings are muffled when building from the Makefile.  It would be nice to enable them, but I don’t know how to fix that.

Sorry it wasn't an obvious one :-/   I agree that there should have
been a warning for this kind of thing, but I don't think warnings were
actually muffled here.  In fact if you use debug mode, the command
line has -Wall and -Werror turned on.

Rather, I think it's because lo_types.h has both lo_server and
lo_address typedef'd to void*, which the compiler treats as
interchangeable.  So technically there is no warning to issue if these
types get mixed up.

There could be ways to fix this using typedef'd structs instead of
void pointers or something like that... I'm not sure whether such a
change wouldn't have pretty bad implications for the API though.  I'll
look into it.

>
> After this fix another bug arose, it looks like data corruption too, but haven’t found out why.

I see it.  Actually I know what's happening here.. it's a weird
interaction between C++ inheritance, implicit casting, and the above
problem.

In my wrapper, the lo::ServerThread class inherits from lo::Server.
They both autocast to their respective lo_serverthread and lo_server
types.  However, I had intended that if you pass a lo::ServerThread to
a function expecting lo_server, it would call the superclass's
lo_server() operator.

Unfortunately this doesn't seem to happen.. instead of upcasting to
lo::Server and calling lo::Server::lo_server(), it silently calls
lo::ServerThread::lo_serverthread() and passes in a lo_serverthread to
lo_message_send_from, where a lo_server is expected.

This is, I presume, rooted in the whole problem of void* typedefs
being considered equal in C, if I understand correctly.  The C++
compiler doesn't see the need to pass in a lo_server rather than
lo_serverthread, and therefore doesn't cast correctly.

You can fix the bug by changing the line,

a.send_from(st, "test1", "i", 20);

to:

a.send_from((lo::Server&)st, "test1", "i", 20);

Weirdly, if you don't use a reference it doesn't compile:

a.send_from((lo::Server)st, "test1", "i", 20);

apparently in this case it is trying to call a non-existing copy
constructor, I'm not sure why.

Anyways, I'm just looking for a better solution, trying to get the
implicit cast to work as I intended, but I haven't got it figured out
just yet.  At worst case overloading could be used to fix it perhaps.

Steve

Hi Steve,

A little story ...

When running cpp_test built for i386.
If I comment the cpp_test.cpp:152, no error occurs.

    a.send_from(st, "test1", "i", 20);

More precisely, the same happens if lo_cpp.h:138 is commented:

    int r = lo_send_message_from(from, address, path, m);


Running cpp_test in lldb shows that the error occurs when lo_server_free is called:

frame #4: 0x0007eede liblo.7.dylib`lo_server_free(s=0x0014f720) + 350 at server.c:726
   723 	            s->ai = NULL;
   724 	        }
   725 	        if (s->hostname) {
-> 726 	            free(s->hostname);
   727 	            s->hostname = NULL;
   728 	        }
   729 	        if (s->path) {

At this point s->hostname == 0x9

I stepped around the call at lo_cpp.h:138 and found that the hostname field of the lo_server was as expected “” (empty string) before the call as expected, then became 0x1 when entered in the body of lo_send_message_from!

Still stepping, at send.c:541, I can see “a->errnum = geterror()“ where a is a lo_address and errnum == 0x9.  It became clear that there was a problem in the function call.  Going back to lo_cpp.h showed that lo_send_message_from was called with the first two arguments swapped.

“That was easy”, but took me two hours!  How can we avoid that?  I believe for some reason the warnings are muffled when building from the Makefile.  It would be nice to enable them, but I don’t know how to fix that.

After this fix another bug arose, it looks like data corruption too, but haven’t found out why.


Best,
Cam


On 26 nov. 2013, at 10:49, Camille Troillard <ca...@os...> wrote:

>> However, when clang++ is not selected (and therefore cpp_test is not
>> built), then "make test" is successful for me.  I have XCode 5.0.2
>> installed.
>> 
>> By the way, another way to compile for multiple architectures is the
>> following, which also results in a successful "make test" for me on
>> 10.8:
>> 
>> ./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
>> -arch x86_64' CC=clang CXX=clang++
>> 
>> or, to use gcc:
>> 
>> ./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
>> -arch x86_64' --disable-dependency-tracking

Hello Steve,


On 26 nov. 2013, at 10:28, Stephen Sinclair <rad...@gm...> wrote:

> So, I don't seem to get this error on 10.8.  On the other hand I do
> get a segfault in cpp_test when configured with,
> 
> ./configure CXXFLAGS="-m32" CFLAGS="-m32" LDFLAGS="-m32" CC=clang CXX=clang++

I confirm this, but I am using Xcode 4.6.3.


> (but not when compiled for 64-bit)
> 
> However, when clang++ is not selected (and therefore cpp_test is not
> built), then "make test" is successful for me.  I have XCode 5.0.2
> installed.
> 
> By the way, another way to compile for multiple architectures is the
> following, which also results in a successful "make test" for me on
> 10.8:
> 
> ./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
> -arch x86_64' CC=clang CXX=clang++
> 
> or, to use gcc:
> 
> ./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
> -arch x86_64' --disable-dependency-tracking

Here, I guess the 64bit part of the code gets executed.


Cam

On Mon, Nov 25, 2013 at 5:59 PM, Camille Troillard
<ca...@os...> wrote:
>
> On 25 nov. 2013, at 17:43, Stephen Sinclair <rad...@gm...> wrote:
>
>> On Mon, Nov 25, 2013 at 4:59 PM, Simon Newton <li...@no...> wrote:
>>> I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.
>>>
>>> I'll test on a Pi and x86 Debian machine soon and report back.
>>
>> Huh.. This, I've never seen before:
>>
>> passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI",
>> 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt,
>> 0.9999, "sym", 'X', 'Y', LO_ARGS_ENliblo error: lo_send,
>> lo_message_add, or lo_message_add_varargs called with mismatching
>> types and data at
>> testlo.c:1005, exiting.
>> liblo error: lo_send or lo_message_add called with invalid symbol
>> pointer for arg 9, probably arg mismatch
>> at testlo.c:1005, exiting.
>>
>>
>> Seems there's some problem occurring with the "sym" argument?  i can't
>> imagine why...
>> What kind of machine are you running on?  MacBook? x86-64?
>
> Steve, I tried with a 32bits build of liblo on OS X 10.9/Xcode 5 and got problems too.
>
> I compiled liblo with: CXXFLAGS="-m32" CFLAGS="-m32" LDFLAGS="-m32"  ./configure
>
> Can it be a problem with LO_ARGS_END?
>
> Then, I compiled the usual way, producing 64bits executables, and noticed there was a false positive, or what I suspect to be a false positive.  Please look for "liblo error: lo_send, lo_message_add” in liblo-0.28rc-test_x64.log.


So, I don't seem to get this error on 10.8.  On the other hand I do
get a segfault in cpp_test when configured with,

./configure CXXFLAGS="-m32" CFLAGS="-m32" LDFLAGS="-m32" CC=clang CXX=clang++

(but not when compiled for 64-bit)

However, when clang++ is not selected (and therefore cpp_test is not
built), then "make test" is successful for me.  I have XCode 5.0.2
installed.

By the way, another way to compile for multiple architectures is the
following, which also results in a successful "make test" for me on
10.8:

./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
-arch x86_64' CC=clang CXX=clang++

or, to use gcc:

./configure CFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386
-arch x86_64' --disable-dependency-tracking


Steve

Confirmed the tests are passing on Debian Wheezy.

uname -a

Linux windu 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

Simon


On Mon, Nov 25, 2013 at 9:17 AM, Simon Newton <li...@no...> wrote:
> simon:~ $ uname -a
> Darwin macbookpro 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
> 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
>
> On Mon, Nov 25, 2013 at 8:43 AM, Stephen Sinclair <rad...@gm...> wrote:
>> On Mon, Nov 25, 2013 at 4:59 PM, Simon Newton <li...@no...> wrote:
>>> I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.
>>>
>>> I'll test on a Pi and x86 Debian machine soon and report back.
>>>
>>> Simon
>>>
>>
>>
>>
>> Huh.. This, I've never seen before:
>>
>> passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI",
>> 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt,
>> 0.9999, "sym", 'X', 'Y', LO_ARGS_ENliblo error: lo_send,
>> lo_message_add, or lo_message_add_varargs called with mismatching
>> types and data at
>> testlo.c:1005, exiting.
>> liblo error: lo_send or lo_message_add called with invalid symbol
>> pointer for arg 9, probably arg mismatch
>> at testlo.c:1005, exiting.
>>
>>
>> Seems there's some problem occurring with the "sym" argument?  i can't
>> imagine why...
>> What kind of machine are you running on?  MacBook? x86-64?
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

simon:~ $ uname -a
Darwin macbookpro 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19
22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

On Mon, Nov 25, 2013 at 8:43 AM, Stephen Sinclair <rad...@gm...> wrote:
> On Mon, Nov 25, 2013 at 4:59 PM, Simon Newton <li...@no...> wrote:
>> I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.
>>
>> I'll test on a Pi and x86 Debian machine soon and report back.
>>
>> Simon
>>
>
>
>
> Huh.. This, I've never seen before:
>
> passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI",
> 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt,
> 0.9999, "sym", 'X', 'Y', LO_ARGS_ENliblo error: lo_send,
> lo_message_add, or lo_message_add_varargs called with mismatching
> types and data at
> testlo.c:1005, exiting.
> liblo error: lo_send or lo_message_add called with invalid symbol
> pointer for arg 9, probably arg mismatch
> at testlo.c:1005, exiting.
>
>
> Seems there's some problem occurring with the "sym" argument?  i can't
> imagine why...
> What kind of machine are you running on?  MacBook? x86-64?
>
> Steve
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On 25 nov. 2013, at 17:43, Stephen Sinclair <rad...@gm...> wrote:

> On Mon, Nov 25, 2013 at 4:59 PM, Simon Newton <li...@no...> wrote:
>> I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.
>> 
>> I'll test on a Pi and x86 Debian machine soon and report back.
> 
> Huh.. This, I've never seen before:
> 
> passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI",
> 0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt,
> 0.9999, "sym", 'X', 'Y', LO_ARGS_ENliblo error: lo_send,
> lo_message_add, or lo_message_add_varargs called with mismatching
> types and data at
> testlo.c:1005, exiting.
> liblo error: lo_send or lo_message_add called with invalid symbol
> pointer for arg 9, probably arg mismatch
> at testlo.c:1005, exiting.
> 
> 
> Seems there's some problem occurring with the "sym" argument?  i can't
> imagine why...
> What kind of machine are you running on?  MacBook? x86-64?

Steve, I tried with a 32bits build of liblo on OS X 10.9/Xcode 5 and got problems too.

I compiled liblo with: CXXFLAGS="-m32" CFLAGS="-m32" LDFLAGS="-m32"  ./configure

Can it be a problem with LO_ARGS_END?

Then, I compiled the usual way, producing 64bits executables, and noticed there was a false positive, or what I suspect to be a false positive.  Please look for "liblo error: lo_send, lo_message_add” in liblo-0.28rc-test_x64.log.

On Mon, Nov 25, 2013 at 4:59 PM, Simon Newton <li...@no...> wrote:
> I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.
>
> I'll test on a Pi and x86 Debian machine soon and report back.
>
> Simon
>



Huh.. This, I've never seen before:

passed test_varargs (a, "/lotsofformats", "fisbmhtdSccTFNI",
0.12345678f, 123, "123", btest, midi_data, 0x0123456789abcdefULL, tt,
0.9999, "sym", 'X', 'Y', LO_ARGS_ENliblo error: lo_send,
lo_message_add, or lo_message_add_varargs called with mismatching
types and data at
testlo.c:1005, exiting.
liblo error: lo_send or lo_message_add called with invalid symbol
pointer for arg 9, probably arg mismatch
at testlo.c:1005, exiting.


Seems there's some problem occurring with the "sym" argument?  i can't
imagine why...
What kind of machine are you running on?  MacBook? x86-64?

Steve

I'm seeing failures on 10.9 with both gcc and clang. I've attached the log file.

I'll test on a Pi and x86 Debian machine soon and report back.

Simon



On Mon, Nov 25, 2013 at 5:29 AM, Felipe Sateler <fsa...@gm...> wrote:
> On Mon, Nov 25, 2013 at 10:09 AM, Stephen Sinclair <rad...@gm...> wrote:
>> On Mon, Nov 25, 2013 at 2:01 PM, Felipe Sateler <fsa...@gm...> wrote:
>>> I hit one snag: the configure script munges the CFLAGS to remove
>>> -Werror. However, -Werror can take a parameter (eg,
>>> -Werror=format-security), meaning you end up with an invalid line like
>>> `gcc  =format-security conftest.c`.
>>>
>>> I'm not sure configure should munge the CFLAGS, nor why would it be
>>> necessary (do some configure tests contain invalid code?). Removing
>>> the munging I can build and make test ends successfully
>>
>>
>> Okay, thanks.  Believe me I hated adding code to mess with the flags,
>> but in fact if you pass -Werror, the configure script fails since some
>> tests, in particular AC_CHECK_FUNC, do indeed produce warnings.
>
> Ah, yes, because the function is possibly undeclared.
>
>>
>> I looked up how to deal with this and the recommendation seemed to
>> generally be to ensure -Werror was removed from CFLAGS before any
>> tests.  I would think that adding it back is a mistake rather than
>> just recovering the old CFLAGS variable, but after some tests, new
>> flags may be added if I understand correctly.  (Though now that I
>> think about it, maybe only LIBS would be modified by AC_CHECK_FUNC)
>>
>> I admit I didn't realize Werror could take arguments.  I'll see if I
>> this can be dealt with better, thanks for finding the problem.
>
> Other options to consider:
>
> 1. Emptying up CFLAGS before configure and re set it afterwards. The
> disadvantage is that someone may have put needed -I or other flags
> here (although they should be in CPPFLAGS).
> 2. Adding -Wno-error=<whatever>. This is probably not very
> future-proof, as new warnings get added.
> 3. Don't touch CFLAGS, leave the developer to wonder what happened
> when the tests break after adding -Werror.
> 4. Print a warning when -Werror is detected, and then error out explicitly.
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On Mon, Nov 25, 2013 at 10:09 AM, Stephen Sinclair <rad...@gm...> wrote:
> On Mon, Nov 25, 2013 at 2:01 PM, Felipe Sateler <fsa...@gm...> wrote:
>> I hit one snag: the configure script munges the CFLAGS to remove
>> -Werror. However, -Werror can take a parameter (eg,
>> -Werror=format-security), meaning you end up with an invalid line like
>> `gcc  =format-security conftest.c`.
>>
>> I'm not sure configure should munge the CFLAGS, nor why would it be
>> necessary (do some configure tests contain invalid code?). Removing
>> the munging I can build and make test ends successfully
>
>
> Okay, thanks.  Believe me I hated adding code to mess with the flags,
> but in fact if you pass -Werror, the configure script fails since some
> tests, in particular AC_CHECK_FUNC, do indeed produce warnings.

Ah, yes, because the function is possibly undeclared.

>
> I looked up how to deal with this and the recommendation seemed to
> generally be to ensure -Werror was removed from CFLAGS before any
> tests.  I would think that adding it back is a mistake rather than
> just recovering the old CFLAGS variable, but after some tests, new
> flags may be added if I understand correctly.  (Though now that I
> think about it, maybe only LIBS would be modified by AC_CHECK_FUNC)
>
> I admit I didn't realize Werror could take arguments.  I'll see if I
> this can be dealt with better, thanks for finding the problem.

Other options to consider:

1. Emptying up CFLAGS before configure and re set it afterwards. The
disadvantage is that someone may have put needed -I or other flags
here (although they should be in CPPFLAGS).
2. Adding -Wno-error=<whatever>. This is probably not very
future-proof, as new warnings get added.
3. Don't touch CFLAGS, leave the developer to wonder what happened
when the tests break after adding -Werror.
4. Print a warning when -Werror is detected, and then error out explicitly.


-- 

Saludos,
Felipe Sateler

On Mon, Nov 25, 2013 at 2:19 PM, Camille Troillard
<ca...@os...> wrote:
>
> On 25 nov. 2013, at 14:11, Stephen Sinclair <rad...@gm...> wrote:
>
>> One idea for testing on that last platform would be to just test from
>> the tarball.  That way you don't need to run autogen.sh, but rather
>> just run configure.
>
> Ah, I like this!
> The tests are also successful on OS X 10.6 / Xcode 4.2.
>
>
>> Also, let me know if the new version still works with any of your
>> software that uses liblo.
>
> I tried and did not find any problem so far.
> I will do more detailed testing tomorrow.


Thanks Cam!

Steve

On 25 nov. 2013, at 14:11, Stephen Sinclair <rad...@gm...> wrote:

> One idea for testing on that last platform would be to just test from
> the tarball.  That way you don't need to run autogen.sh, but rather
> just run configure.

Ah, I like this!
The tests are also successful on OS X 10.6 / Xcode 4.2.


> Also, let me know if the new version still works with any of your
> software that uses liblo.

I tried and did not find any problem so far.
I will do more detailed testing tomorrow.


Best,
Cam

On Mon, Nov 25, 2013 at 11:56 AM, Camille Troillard
<ca...@os...> wrote:
> Hi Steve,
>
> Thank you for doing this!
> I ran the tests successfully under OS X:
>
> - 10.9 / Xcode 5,
> - 10.8 / Xcode 4.6.3,
>
> I have not been able to test on 10.6 / Xcode 4.2 because the system did not had the required versions for autoconf and automate and it is difficult to cleanly update those installed by Xcode by default (hopefully this is not the case in newer versions).


Cool, thanks!

One idea for testing on that last platform would be to just test from
the tarball.  That way you don't need to run autogen.sh, but rather
just run configure.

Also, let me know if the new version still works with any of your
software that uses liblo.

thanks,
Steve

On Mon, Nov 25, 2013 at 2:01 PM, Felipe Sateler <fsa...@gm...> wrote:
> I hit one snag: the configure script munges the CFLAGS to remove
> -Werror. However, -Werror can take a parameter (eg,
> -Werror=format-security), meaning you end up with an invalid line like
> `gcc  =format-security conftest.c`.
>
> I'm not sure configure should munge the CFLAGS, nor why would it be
> necessary (do some configure tests contain invalid code?). Removing
> the munging I can build and make test ends successfully


Okay, thanks.  Believe me I hated adding code to mess with the flags,
but in fact if you pass -Werror, the configure script fails since some
tests, in particular AC_CHECK_FUNC, do indeed produce warnings.

I looked up how to deal with this and the recommendation seemed to
generally be to ensure -Werror was removed from CFLAGS before any
tests.  I would think that adding it back is a mistake rather than
just recovering the old CFLAGS variable, but after some tests, new
flags may be added if I understand correctly.  (Though now that I
think about it, maybe only LIBS would be modified by AC_CHECK_FUNC)

I admit I didn't realize Werror could take arguments.  I'll see if I
this can be dealt with better, thanks for finding the problem.

Steve

I hit one snag: the configure script munges the CFLAGS to remove
-Werror. However, -Werror can take a parameter (eg,
-Werror=format-security), meaning you end up with an invalid line like
`gcc  =format-security conftest.c`.

I'm not sure configure should munge the CFLAGS, nor why would it be
necessary (do some configure tests contain invalid code?). Removing
the munging I can build and make test ends successfully

On Mon, Nov 25, 2013 at 7:56 AM, Camille Troillard
<ca...@os...> wrote:
> Hi Steve,
>
> Thank you for doing this!
> I ran the tests successfully under OS X:
>
> - 10.9 / Xcode 5,
> - 10.8 / Xcode 4.6.3,
>
> I have not been able to test on 10.6 / Xcode 4.2 because the system did not had the required versions for autoconf and automate and it is difficult to cleanly update those installed by Xcode by default (hopefully this is not the case in newer versions).
>
>
> Best Regards,
> Camille
>
>
> On 22 nov. 2013, at 16:29, Stephen Sinclair <rad...@gm...> wrote:
>
>> Hello,
>>
>> Since there haven't been many developments on liblo lately and yet
>> there are some important bugfixes in master, I am putting together a
>> release candidate to encourage further testing.
>>
>> I have merged the C++ branch and have been fixing various small errors
>> and build problems on Linux and OS X.
>>
>> Note that on OS X to use the C++11 bindings you must configure using
>> the following command:
>>
>> ./configure CC='clang' CXX='clang++'
>>
>> Since the version of gcc bundled with XCode does not support C++11.
>> The configure script should automatically add the required flags to
>> turn on C++11 support for clang++.
>>
>> Steve
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel



-- 

Saludos,
Felipe Sateler