liblo-devel — Discussion of liblo library and application development

[liblo] liblo issues on WSL Ubuntu 18.04 LTS

[Avery C. <a.c...@gm...>]

I get this error message when trying to use an application that has [OSC
support.
I've compiled version 0.28, 0.29 and 0.30 from source, as well as tried the
available repo package *liblo-devel* with no luck.

*liblo server error -8 in path (null): Servname not supported for
ai_socktype*
Could not start a server with port url, multicast group osc.udp://:9000

I can recreate this error with oscdump, by incorrectly using it like so:
*oscdump test osc.udp://:9000*

Re: [liblo] how to connect to a liblo TCP OSC server?

[Stephen S. <rad...@gm...>]

Sorry to not answer sooner.

The "s" and "S" thing is because OSC has two types to distinguish from
"strings" and "symbols", this comes from its history of modeling
messaging within the Max / PureData-style environments.
As far as data structures go, the lo_arg is a union, so it doesn't
really matter whether you use "s" or "S", as they have the same
address, but from a semantic point of view you should use "s" if the
type is LO_STRING and "S" if the type is LO_SYMBOL.  But it's only
necessary to distinguish if your program distinguishes those types
(eg. messages from PureData may distinguish them), otherwise you can
feel free to treat symbols as strings.

Steve

On Tue, Mar 2, 2021 at 8:43 AM Fernando Carello <fca...@gm...> wrote:
>
> Thank you guys!
>
> Fernando
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Fernando C. <fca...@gm...>]

Thank you guys!

Fernando

Re: [liblo] how to connect to a liblo TCP OSC server?

[Mark H. <Ma...@re...>]

Thanks for the tip, Thomas.

There is indeed a lot of usage information in that file.

mark


-----Original Message-----
From: Thomas Brand [mailto:to...@tr...]
Sent: Monday, March 01, 2021 10:20 AM
To: liblo development list
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?


On 2021-03-01 11:32, Fernando Carello wrote:
> Hello Mark, thanks for replying.
> 
> So I can simply access the fields of the "argv" union, based upon the
> value of "type". Excellent.
> 
> I looked at lo_osc_types.h as a reference.
> It seems to me, that some types may have more than one corresponding
> field. How to choose?
> 
> Example 1:
> I have type = LO_STRING, which is 's'
> Should I read &argv[n]->S or &argv[n]->s ?
> 
> Example 2:
> I have type = LO_INT32, which is 'i'
> Should I read argv[n]->i or argv[n]->i32 ?
> 
> Same goes for 'f' (read from ->f or ->f32 ?)
> 
> Thanks for the clarification
> 
> Fernando
> 

Hi Fernando
in that case s and f are good to use.
For a broad overview on all operations, the code in src/testlo.c has it 
all, a nice cheat-sheet.
Ciao
Thomas


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Mark H. <Ma...@re...>]

Hi Fernando,

Those are good questions, and my answer is "I don't know". I only use "i",
"f" and "s", and haven't had any issues.

Fortunately, Thomas's tip about "testlo.c" might be all that you need. I've
added it to my reference documents.

mark


-----Original Message-----
From: Fernando Carello [mailto:fca...@gm...]
Sent: Monday, March 01, 2021 3:32 AM
To: liblo development list
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?


Hello Mark, thanks for replying.

So I can simply access the fields of the "argv" union, based upon the
value of "type". Excellent.

I looked at lo_osc_types.h as a reference.
It seems to me, that some types may have more than one corresponding
field. How to choose?

Example 1:
I have type = LO_STRING, which is 's'
Should I read &argv[n]->S or &argv[n]->s ?

Example 2:
I have type = LO_INT32, which is 'i'
Should I read argv[n]->i or argv[n]->i32 ?

Same goes for 'f' (read from ->f or ->f32 ?)

Thanks for the clarification

Fernando



Il giorno dom 28 feb 2021 alle ore 23:34 Mark Hotchkiss
<Ma...@re...> ha scritto:
>
> Hi Fernando,
>
> I assume that you are talking about fetching the passed values out from a
received message in the message handler. The values are each passed in a
union.
>
> Here is one of my message handlers (sorry if it doesn't format well in an
email):
>
>
> //      Callback handler for "/request/write <id> <node> <location>
<parameter size> <parameter ID> <parameter format> <value>"
>
> //                              or                       <id> <node>
<location> <parameter name> <parameter format> <value>"
>
> int             handler_reqwrite(const char *path, const char *types,
lo_arg **argv, int argc, lo_message msg, void *user_data)
>
> {
>         if ( *(types+3) == 'i')
// if the forth parameter is a size and not a name . . .
>
>                 if ( argv[2]->i == -1 )
// and if the location is ram and not a flash page . . .
>
>                         requestWrite( (void*)argv[0]->i, argv[1]->i,
argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
>                 else
>                         requestWriteFlash( (void*)argv[0]->i, argv[1]->i,
argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
>         else
// if the forth parameter is a name and not a size . . .
>
>                 if ( argv[2]->i == -1 )
// and if the location is ram and not a flash page . . .
>
>                         requestWriteByName( (void*)argv[0]->i, argv[1]->i,
&argv[3]->s, argv[4]->i, argv[5]);
>                 else
>                         requestWriteFlashByName( (void*)argv[0]->i,
argv[1]->i, &argv[3]->s, argv[4]->i, argv[5]);
>         return 0;
> }
>
>
> Each 'lo_arg' type is a union of all of the OSC types and each 'argv' is a
pointer to a union. As an example, if the second value passed was an 'int',
then I would access it as:
>
>         int size = argv[1]->i ;
>
> and if it was a string (which is actually a character-pointer, so we have
a pointer to a pointer):
>
>         char* name = &argv[1]->s ;
>
> Of course, the 'types' parameter would tell you the true type of the
parameter so that you can access it correctly, and I have caused
segmentation faults when I made the wrong assumption of the type.
>
> Is that what you needed? Let me know if you would like anything else. I
have a ton of code now.
>
> Mark
>
>
>
> -----Original Message-----
> From: Fernando Carello [mailto:fca...@gm...]
> Sent: Sunday, February 28, 2021 9:00 AM
> To: liblo development list
> Subject: Re: [liblo] how to connect to a liblo TCP OSC server?
>
>
> Hello,
> I've successfully tested liblo in C, writing both client and server
> implementations.
>
> Now I'm faced with a maybe silly problem...
>
> I can compose an OSC message from native C types using
> lo_message_new() and appropriate
> lo_message_add_* methods.
>
> But, how may I convert OSC arguments from lo_arg to native C types?
>
> Thanks!
> Fernando
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Thomas B. <to...@tr...>]

On 2021-03-01 11:32, Fernando Carello wrote:
> Hello Mark, thanks for replying.
> 
> So I can simply access the fields of the "argv" union, based upon the
> value of "type". Excellent.
> 
> I looked at lo_osc_types.h as a reference.
> It seems to me, that some types may have more than one corresponding
> field. How to choose?
> 
> Example 1:
> I have type = LO_STRING, which is 's'
> Should I read &argv[n]->S or &argv[n]->s ?
> 
> Example 2:
> I have type = LO_INT32, which is 'i'
> Should I read argv[n]->i or argv[n]->i32 ?
> 
> Same goes for 'f' (read from ->f or ->f32 ?)
> 
> Thanks for the clarification
> 
> Fernando
> 

Hi Fernando
in that case s and f are good to use.
For a broad overview on all operations, the code in src/testlo.c has it 
all, a nice cheat-sheet.
Ciao
Thomas

Re: [liblo] how to connect to a liblo TCP OSC server?

[Fernando C. <fca...@gm...>]

Hello Mark, thanks for replying.

So I can simply access the fields of the "argv" union, based upon the
value of "type". Excellent.

I looked at lo_osc_types.h as a reference.
It seems to me, that some types may have more than one corresponding
field. How to choose?

Example 1:
I have type = LO_STRING, which is 's'
Should I read &argv[n]->S or &argv[n]->s ?

Example 2:
I have type = LO_INT32, which is 'i'
Should I read argv[n]->i or argv[n]->i32 ?

Same goes for 'f' (read from ->f or ->f32 ?)

Thanks for the clarification

Fernando



Il giorno dom 28 feb 2021 alle ore 23:34 Mark Hotchkiss
<Ma...@re...> ha scritto:
>
> Hi Fernando,
>
> I assume that you are talking about fetching the passed values out from a received message in the message handler. The values are each passed in a union.
>
> Here is one of my message handlers (sorry if it doesn't format well in an email):
>
>
> //      Callback handler for "/request/write <id> <node> <location> <parameter size> <parameter ID> <parameter format> <value>"
>
> //                              or                       <id> <node> <location> <parameter name> <parameter format> <value>"
>
> int             handler_reqwrite(const char *path, const char *types, lo_arg **argv, int argc, lo_message msg, void *user_data)
>
> {
>         if ( *(types+3) == 'i')                                                 // if the forth parameter is a size and not a name . . .
>
>                 if ( argv[2]->i == -1 )                                         // and if the location is ram and not a flash page . . .
>
>                         requestWrite( (void*)argv[0]->i, argv[1]->i, argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
>                 else
>                         requestWriteFlash( (void*)argv[0]->i, argv[1]->i, argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
>         else                                                                                                    // if the forth parameter is a name and not a size . . .
>
>                 if ( argv[2]->i == -1 )                                         // and if the location is ram and not a flash page . . .
>
>                         requestWriteByName( (void*)argv[0]->i, argv[1]->i, &argv[3]->s, argv[4]->i, argv[5]);
>                 else
>                         requestWriteFlashByName( (void*)argv[0]->i, argv[1]->i, &argv[3]->s, argv[4]->i, argv[5]);
>         return 0;
> }
>
>
> Each 'lo_arg' type is a union of all of the OSC types and each 'argv' is a pointer to a union. As an example, if the second value passed was an 'int', then I would access it as:
>
>         int size = argv[1]->i ;
>
> and if it was a string (which is actually a character-pointer, so we have a pointer to a pointer):
>
>         char* name = &argv[1]->s ;
>
> Of course, the 'types' parameter would tell you the true type of the parameter so that you can access it correctly, and I have caused segmentation faults when I made the wrong assumption of the type.
>
> Is that what you needed? Let me know if you would like anything else. I have a ton of code now.
>
> Mark
>
>
>
> -----Original Message-----
> From: Fernando Carello [mailto:fca...@gm...]
> Sent: Sunday, February 28, 2021 9:00 AM
> To: liblo development list
> Subject: Re: [liblo] how to connect to a liblo TCP OSC server?
>
>
> Hello,
> I've successfully tested liblo in C, writing both client and server
> implementations.
>
> Now I'm faced with a maybe silly problem...
>
> I can compose an OSC message from native C types using
> lo_message_new() and appropriate
> lo_message_add_* methods.
>
> But, how may I convert OSC arguments from lo_arg to native C types?
>
> Thanks!
> Fernando
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Mark H. <Ma...@re...>]

Hi Fernando,

I assume that you are talking about fetching the passed values out from a
received message in the message handler. The values are each passed in a
union.

Here is one of my message handlers (sorry if it doesn't format well in an
email):


//	Callback handler for "/request/write <id> <node> <location>
<parameter size> <parameter ID> <parameter format> <value>"
//				or			 <id> <node>
<location> <parameter name> <parameter format> <value>"
int		handler_reqwrite(const char *path, const char *types, lo_arg
**argv, int argc, lo_message msg, void *user_data)
{
	if ( *(types+3) == 'i')
// if the forth parameter is a size and not a name . . .
		if ( argv[2]->i == -1 )
// and if the location is ram and not a flash page . . .
			requestWrite( (void*)argv[0]->i, argv[1]->i,
argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
		else
			requestWriteFlash( (void*)argv[0]->i, argv[1]->i,
argv[3]->i, argv[4]->i, argv[5]->i, argv[6]);
	else
// if the forth parameter is a name and not a size . . .
		if ( argv[2]->i == -1 )
// and if the location is ram and not a flash page . . .
			requestWriteByName( (void*)argv[0]->i, argv[1]->i,
&argv[3]->s, argv[4]->i, argv[5]);
		else
			requestWriteFlashByName( (void*)argv[0]->i,
argv[1]->i, &argv[3]->s, argv[4]->i, argv[5]);
	return 0;
}


Each 'lo_arg' type is a union of all of the OSC types and each 'argv' is a
pointer to a union. As an example, if the second value passed was an 'int',
then I would access it as:

	int size = argv[1]->i ;

and if it was a string (which is actually a character-pointer, so we have a
pointer to a pointer):

	char* name = &argv[1]->s ;

Of course, the 'types' parameter would tell you the true type of the
parameter so that you can access it correctly, and I have caused
segmentation faults when I made the wrong assumption of the type.

Is that what you needed? Let me know if you would like anything else. I have
a ton of code now.

Mark



-----Original Message-----
From: Fernando Carello [mailto:fca...@gm...]
Sent: Sunday, February 28, 2021 9:00 AM
To: liblo development list
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?


Hello,
I've successfully tested liblo in C, writing both client and server
implementations.

Now I'm faced with a maybe silly problem...

I can compose an OSC message from native C types using
lo_message_new() and appropriate
lo_message_add_* methods.

But, how may I convert OSC arguments from lo_arg to native C types?

Thanks!
Fernando


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Fernando C. <fca...@gm...>]

Hello,
I've successfully tested liblo in C, writing both client and server
implementations.

Now I'm faced with a maybe silly problem...

I can compose an OSC message from native C types using
lo_message_new() and appropriate
lo_message_add_* methods.

But, how may I convert OSC arguments from lo_arg to native C types?

Thanks!
Fernando

Re: [liblo] Behringer /xremote and /xremotenfb commands

[Goran M. <me...@ti...>]

On Mon, Jan 04, 2021 at 10:45:41PM -0400, Joseph Malloch wrote:
> Hi Meka,
>
> I haven’t looked at your source code but I did successfully send and receive OSC messages with the paths “/xremote” and “/xremotenfb” using the oscsend and oscdump utilities. They worked just as expected.
I tried that too, so if you can tell me which osc* commands did you use
exactly, I would be gratefull. In the mean time, I checked firewall
(explicit rule for allowing communication with the mixer as well as
turning the firewall off) with the same results.

These lines of code are of the interest, I would say:
https://github.com/maolan/maomix/blob/master/maomix/connection.hpp#L24
https://github.com/maolan/maomix/blob/master/src/connection.cpp#L240

It's even weirder as it worked only once with this code, so I'm
confused. The problem is that only /xremote{,nfb} commands don't work as
expected. Weird!

Regards,
meka

Re: [liblo] Behringer /xremote and /xremotenfb commands

[Joseph M. <jos...@gm...>]

Hi Meka,

I haven’t looked at your source code but I did successfully send and receive OSC messages with the paths “/xremote” and “/xremotenfb” using the oscsend and oscdump utilities. They worked just as expected.

Cheers,
Joe


> On Dec 30, 2020, at 5:25 PM, Goran Mekić <meka@tilda.center> wrote:
> 
> Hello,
> 
> First of all, thank you for the wonderful lib. I'm using it to develop
> an app to control my XR18 (and other mixers, once I get my hands on
> them). The app is open source at https://github.com/maolan/maomix.
> 
> I can't seem to send /xremote or /xremotenfb commands. To be exact, I
> never get a reply. This is exact line I'm sending it from:
> https://github.com/maolan/maomix/blob/master/src/connection.cpp#L239
> 
> To be honest, same thing happens if I use "oscsend <ip> 10024 /xremote".
> Does anyone on this list have experience why this particular command is
> special and in what way?
> 
> I do have a problem understanding /meters, too, but at least I get reply
> using /meters/* commands.
> 
> Regards,
> meka
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

[liblo] Behringer /xremote and /xremotenfb commands

[Goran M. <me...@ti...>]

Hello,

First of all, thank you for the wonderful lib. I'm using it to develop
an app to control my XR18 (and other mixers, once I get my hands on
them). The app is open source at https://github.com/maolan/maomix.

I can't seem to send /xremote or /xremotenfb commands. To be exact, I
never get a reply. This is exact line I'm sending it from:
https://github.com/maolan/maomix/blob/master/src/connection.cpp#L239

To be honest, same thing happens if I use "oscsend <ip> 10024 /xremote".
Does anyone on this list have experience why this particular command is
special and in what way?

I do have a problem understanding /meters, too, but at least I get reply
using /meters/* commands.

Regards,
meka

Re: [liblo] how to connect to a liblo TCP OSC server?

[Stephen S. <rad...@gm...>]

I just added a few comments to lo_message_get_source() and lo_send_from()
to try and clarify this.
Not on the web yet, but if you check master on github you'll see it.
Please let me know if anything could be clearer.

https://github.com/radarsat1/liblo/blob/master/lo/lo.h.in#L136
https://github.com/radarsat1/liblo/blob/master/lo/lo_lowlevel.h#L311

Steve


On Mon, Aug 10, 2020 at 11:44 AM Aigner Roland <
rol...@fh...> wrote:

> Hi Mark and Steve,
>
>
>
> All valid points! At least to me it was confusing, as I’m probably coming
> from a slightly different angle (non-music, generic multimedia
> installations).
>
>
>
> As you suggested, Steve, it’s maybe a good idea to shortly point it out in
> the docs and/or code comments. I must admit, I never read the OSC specs in
> detail, even though I’m using it for quite some time now. My bad, probably
> would have helped.
>
>
>
> Best,
>
> Roland
>
>
>
>
>
> *From:* Mark Hotchkiss <Ma...@re...>
> *Sent:* Thursday, August 6, 2020 10:26 PM
> *To:* 'liblo development list' <lib...@li...>
> *Subject:* Re: [liblo] how to connect to a liblo TCP OSC server?
>
>
>
> Hi Stephen and Roland,
>
>
>
> I interpreted "server" as a device that provides a service. In the context
> of OSC, the server receives requests to provide music, rather than data.
>
>
>
> mark
>
> -----Original Message-----
> *From:* Stephen Sinclair [mailto:rad...@gm... <rad...@gm...>
> ]
> *Sent:* Thursday, August 06, 2020 8:44 AM
> *To:* liblo development list
> *Subject:* Re: [liblo] how to connect to a liblo TCP OSC server?
>
> Ah right,  you do make a good point ;)
>
>
>
> I believe the terminology choice in this case stems from "device accepting
> connections"  (like an HTTP server), as opposed to "device requesting
> connections" (like an HTTP client).  I can try to clarify that in the docs,
> thanks.
>
>
>
> regards,
>
> Steve
>
>
>
>
>
> On Wed, Aug 5, 2020 at 5:59 PM Aigner Roland <
> rol...@fh...> wrote:
>
> Hi Steve,
>
>
>
> Thanks for your detailed reply, that did indeed help. The cause for
> confusion is in fact terminology and what I would associate with the term
> “server” (i.e. a device providing data) and that the notation is apparently
> different here (a device consuming data).
>
>
>
> Also thanks a ton for providing liblo as free software, it’s real helpful!
>
>
>
> Best,
>
> Roland
>
>
>
>
>
>
>
> *From:* Stephen Sinclair <rad...@gm...>
> *Sent:* Tuesday, August 4, 2020 6:16 PM
> *To:* liblo development list <lib...@li...>
> *Subject:* Re: [liblo] how to connect to a liblo TCP OSC server?
>
>
>
> Hi Roland,
>
>
>
>
>
> On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland <
> rol...@fh...> wrote:
>
> However I struggle to figure out how I would connect a client to this
> server, i.e. what the code should look like for a client receiving the data
> sent by this server.
>
>
>
> I'm not sure if your concept of client and server is mixed up here?  In
> OSC it is the client sending data to the server.
>
>
>
> Documentation and sample code leave me scratching my head, I tried to
> figure out by checking the library source code, but so far I failed to
> understand. From the fact that lo_send_message_from requires a target
> address I infer that I would have to iterate through all connected clients
> and sent to the respective sockets manually.
>
>
>
> You can get a target address by creating one, if you know the destination,
> or you can get the sender's address from inside a message handler:
>
>
>
>     lo_address a = lo_message_get_source(data);
>
>     lo_send(a, "/hi", "i", 3);
>
>
>
> But how do I know when a client connection gets accepted?
>
>
>
> Who knows?  The server knows because a handler is being executed.  The
> client only knows whether the send failed.
>
>
>
>
>
> So, summarizing, my two remaining questions are
>
>    1. how do I connect a client to the server?
>
>
>
> Your code (which I snipped from the message, apologies) is correct.  You
> just create a server and specify LO_TCP for its protocol, and a client
> specifying LO_TCP for its protocol.  Then the client should be able to make
> a connection to the server and send it a message.
>
>
>
>
>
>
>
>    1. how do I know what clients are currently connected that I would
>    have to send my packages to?
>
>
>
> Hm, I don't think liblo provides a way to enumerate the current client
> connections.. could be interesting, but it's not too usual to want to
> broadcast to a random client.  Usually messages from the server are limited
> to _responses_ that are sent during message handlers, and in that case you
> can get the response destination using lo_message_get_source as I outlined
> above.
>
>
>
> Note that if your *client* wants to receive a response... actually it
> cannot, it needs to set up a *server* to receive the response, and use
> lo_send_from, specifying that server.  That's how the destination server
> can find where to send responses back to.  So for bidirectional messaging,
> each side has a server.
>
>
>
> If you need to broadcast a message to multiple servers, you can look into
> multicast or broadcast messaging, but that's for UDP.
>
>
>
> As for sending a message to all currently connected clients, I'm not
> sure.. I'll have to think on how to do that and whether it's a good idea.
> Theoretically it is possible.
>
>
>
> Keep in mind that OSC is typically a UDP protocol and is designed around
> one-way messaging.  Liblo incidentally supports responses, but it's common
> for UDP protocols to be unidirectional.
>
> On the TCP side, often clients will make a connection, send a message,
> *maybe* wait for a response, and then close the connection.  Long-lived
> connections are more rarely used; but if they are, they shouldn't *depend*
> on the connection state.
>
>
>
> Hope this helps,
>
> Steve
>
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Re: [liblo] how to connect to a liblo TCP OSC server?

[Aigner R. <rol...@fh...>]

Hi Mark and Steve,

All valid points! At least to me it was confusing, as I’m probably coming from a slightly different angle (non-music, generic multimedia installations).

As you suggested, Steve, it’s maybe a good idea to shortly point it out in the docs and/or code comments. I must admit, I never read the OSC specs in detail, even though I’m using it for quite some time now. My bad, probably would have helped.

Best,
Roland


From: Mark Hotchkiss <Ma...@re...>
Sent: Thursday, August 6, 2020 10:26 PM
To: 'liblo development list' <lib...@li...>
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?

Hi Stephen and Roland,

I interpreted "server" as a device that provides a service. In the context of OSC, the server receives requests to provide music, rather than data.

mark
-----Original Message-----
From: Stephen Sinclair [mailto:rad...@gm...]
Sent: Thursday, August 06, 2020 8:44 AM
To: liblo development list
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?
Ah right,  you do make a good point ;)

I believe the terminology choice in this case stems from "device accepting connections"  (like an HTTP server), as opposed to "device requesting connections" (like an HTTP client).  I can try to clarify that in the docs, thanks.

regards,
Steve


On Wed, Aug 5, 2020 at 5:59 PM Aigner Roland <rol...@fh...<mailto:rol...@fh...>> wrote:
Hi Steve,

Thanks for your detailed reply, that did indeed help. The cause for confusion is in fact terminology and what I would associate with the term “server” (i.e. a device providing data) and that the notation is apparently different here (a device consuming data).

Also thanks a ton for providing liblo as free software, it’s real helpful!

Best,
Roland



From: Stephen Sinclair <rad...@gm...<mailto:rad...@gm...>>
Sent: Tuesday, August 4, 2020 6:16 PM
To: liblo development list <lib...@li...<mailto:lib...@li...>>
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?

Hi Roland,


On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland <rol...@fh...<mailto:rol...@fh...>> wrote:

However I struggle to figure out how I would connect a client to this server, i.e. what the code should look like for a client receiving the data sent by this server.

I'm not sure if your concept of client and server is mixed up here?  In OSC it is the client sending data to the server.


Documentation and sample code leave me scratching my head, I tried to figure out by checking the library source code, but so far I failed to understand. From the fact that lo_send_message_from requires a target address I infer that I would have to iterate through all connected clients and sent to the respective sockets manually.

You can get a target address by creating one, if you know the destination, or you can get the sender's address from inside a message handler:

    lo_address a = lo_message_get_source(data);
    lo_send(a, "/hi", "i", 3);


But how do I know when a client connection gets accepted?

Who knows?  The server knows because a handler is being executed.  The client only knows whether the send failed.



So, summarizing, my two remaining questions are

  1.  how do I connect a client to the server?

Your code (which I snipped from the message, apologies) is correct.  You just create a server and specify LO_TCP for its protocol, and a client specifying LO_TCP for its protocol.  Then the client should be able to make a connection to the server and send it a message.




  1.  how do I know what clients are currently connected that I would have to send my packages to?

Hm, I don't think liblo provides a way to enumerate the current client connections.. could be interesting, but it's not too usual to want to broadcast to a random client.  Usually messages from the server are limited to _responses_ that are sent during message handlers, and in that case you can get the response destination using lo_message_get_source as I outlined above.

Note that if your client wants to receive a response... actually it cannot, it needs to set up a server to receive the response, and use lo_send_from, specifying that server.  That's how the destination server can find where to send responses back to.  So for bidirectional messaging, each side has a server.

If you need to broadcast a message to multiple servers, you can look into multicast or broadcast messaging, but that's for UDP.

As for sending a message to all currently connected clients, I'm not sure.. I'll have to think on how to do that and whether it's a good idea.  Theoretically it is possible.

Keep in mind that OSC is typically a UDP protocol and is designed around one-way messaging.  Liblo incidentally supports responses, but it's common for UDP protocols to be unidirectional.
On the TCP side, often clients will make a connection, send a message, maybe wait for a response, and then close the connection.  Long-lived connections are more rarely used; but if they are, they shouldn't depend on the connection state.

Hope this helps,
Steve

_______________________________________________
liblo-devel mailing list
lib...@li...<mailto:lib...@li...>
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] how to connect to a liblo TCP OSC server?

[Mark H. <Ma...@re...>]

Hi Stephen and Roland,
 
I interpreted "server" as a device that provides a service. In the context
of OSC, the server receives requests to provide music, rather than data.
 
mark

-----Original Message-----
From: Stephen Sinclair [mailto:rad...@gm...]
Sent: Thursday, August 06, 2020 8:44 AM
To: liblo development list
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?


Ah right,  you do make a good point ;)

I believe the terminology choice in this case stems from "device accepting
connections"  (like an HTTP server), as opposed to "device requesting
connections" (like an HTTP client).  I can try to clarify that in the docs,
thanks.

regards,
Steve


On Wed, Aug 5, 2020 at 5:59 PM Aigner Roland < rol...@fh...
<mailto:rol...@fh...> > wrote:


Hi Steve,

 

Thanks for your detailed reply, that did indeed help. The cause for
confusion is in fact terminology and what I would associate with the term
“server” (i.e. a device providing data) and that the notation is apparently
different here (a device consuming data). 

 

Also thanks a ton for providing liblo as free software, it’s real helpful!

 

Best, 

Roland

 

 

 

From: Stephen Sinclair < rad...@gm... <mailto:rad...@gm...> > 
Sent: Tuesday, August 4, 2020 6:16 PM
To: liblo development list < lib...@li...
<mailto:lib...@li...> >
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?

 

Hi Roland,

 

 

On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland < rol...@fh...
<mailto:rol...@fh...> > wrote:

However I struggle to figure out how I would connect a client to this
server, i.e. what the code should look like for a client receiving the data
sent by this server.

 

I'm not sure if your concept of client and server is mixed up here?  In OSC
it is the client sending data to the server.

 

Documentation and sample code leave me scratching my head, I tried to figure
out by checking the library source code, but so far I failed to understand.
>From the fact that lo_send_message_from requires a target address I infer
that I would have to iterate through all connected clients and sent to the
respective sockets manually.

 

You can get a target address by creating one, if you know the destination,
or you can get the sender's address from inside a message handler:

 

    lo_address a = lo_message_get_source(data);

    lo_send(a, "/hi", "i", 3);    

 

But how do I know when a client connection gets accepted?

 

Who knows?  The server knows because a handler is being executed.  The
client only knows whether the send failed.

 

 

So, summarizing, my two remaining questions are

1.	how do I connect a client to the server?

 

Your code (which I snipped from the message, apologies) is correct.  You
just create a server and specify LO_TCP for its protocol, and a client
specifying LO_TCP for its protocol.  Then the client should be able to make
a connection to the server and send it a message.

 

 

 

1.	how do I know what clients are currently connected that I would have
to send my packages to?

 

Hm, I don't think liblo provides a way to enumerate the current client
connections.. could be interesting, but it's not too usual to want to
broadcast to a random client.  Usually messages from the server are limited
to _responses_ that are sent during message handlers, and in that case you
can get the response destination using lo_message_get_source as I outlined
above.

 

Note that if your client wants to receive a response... actually it cannot,
it needs to set up a server to receive the response, and use lo_send_from,
specifying that server.  That's how the destination server can find where to
send responses back to.  So for bidirectional messaging, each side has a
server.

 

If you need to broadcast a message to multiple servers, you can look into
multicast or broadcast messaging, but that's for UDP.

 

As for sending a message to all currently connected clients, I'm not sure..
I'll have to think on how to do that and whether it's a good idea.
Theoretically it is possible.

 

Keep in mind that OSC is typically a UDP protocol and is designed around
one-way messaging.  Liblo incidentally supports responses, but it's common
for UDP protocols to be unidirectional.

On the TCP side, often clients will make a connection, send a message, maybe
wait for a response, and then close the connection.  Long-lived connections
are more rarely used; but if they are, they shouldn't depend on the
connection state.

 

Hope this helps,

Steve

 

_______________________________________________
liblo-devel mailing list
lib...@li... <mailto:lib...@li...>

https://lists.sourceforge.net/lists/listinfo/liblo-devel
<https://lists.sourceforge.net/lists/listinfo/liblo-devel> 

Re: [liblo] how to connect to a liblo TCP OSC server?

[Stephen S. <rad...@gm...>]

Ah right,  you do make a good point ;)

I believe the terminology choice in this case stems from "device accepting
connections"  (like an HTTP server), as opposed to "device requesting
connections" (like an HTTP client).  I can try to clarify that in the docs,
thanks.

regards,
Steve


On Wed, Aug 5, 2020 at 5:59 PM Aigner Roland <rol...@fh...>
wrote:

> Hi Steve,
>
>
>
> Thanks for your detailed reply, that did indeed help. The cause for
> confusion is in fact terminology and what I would associate with the term
> “server” (i.e. a device providing data) and that the notation is apparently
> different here (a device consuming data).
>
>
>
> Also thanks a ton for providing liblo as free software, it’s real helpful!
>
>
>
> Best,
>
> Roland
>
>
>
>
>
>
>
> *From:* Stephen Sinclair <rad...@gm...>
> *Sent:* Tuesday, August 4, 2020 6:16 PM
> *To:* liblo development list <lib...@li...>
> *Subject:* Re: [liblo] how to connect to a liblo TCP OSC server?
>
>
>
> Hi Roland,
>
>
>
>
>
> On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland <
> rol...@fh...> wrote:
>
> However I struggle to figure out how I would connect a client to this
> server, i.e. what the code should look like for a client receiving the data
> sent by this server.
>
>
>
> I'm not sure if your concept of client and server is mixed up here?  In
> OSC it is the client sending data to the server.
>
>
>
> Documentation and sample code leave me scratching my head, I tried to
> figure out by checking the library source code, but so far I failed to
> understand. From the fact that lo_send_message_from requires a target
> address I infer that I would have to iterate through all connected clients
> and sent to the respective sockets manually.
>
>
>
> You can get a target address by creating one, if you know the destination,
> or you can get the sender's address from inside a message handler:
>
>
>
>     lo_address a = lo_message_get_source(data);
>
>     lo_send(a, "/hi", "i", 3);
>
>
>
> But how do I know when a client connection gets accepted?
>
>
>
> Who knows?  The server knows because a handler is being executed.  The
> client only knows whether the send failed.
>
>
>
>
>
> So, summarizing, my two remaining questions are
>
>    1. how do I connect a client to the server?
>
>
>
> Your code (which I snipped from the message, apologies) is correct.  You
> just create a server and specify LO_TCP for its protocol, and a client
> specifying LO_TCP for its protocol.  Then the client should be able to make
> a connection to the server and send it a message.
>
>
>
>
>
>
>
>    1. how do I know what clients are currently connected that I would
>    have to send my packages to?
>
>
>
> Hm, I don't think liblo provides a way to enumerate the current client
> connections.. could be interesting, but it's not too usual to want to
> broadcast to a random client.  Usually messages from the server are limited
> to _responses_ that are sent during message handlers, and in that case you
> can get the response destination using lo_message_get_source as I outlined
> above.
>
>
>
> Note that if your *client* wants to receive a response... actually it
> cannot, it needs to set up a *server* to receive the response, and use
> lo_send_from, specifying that server.  That's how the destination server
> can find where to send responses back to.  So for bidirectional messaging,
> each side has a server.
>
>
>
> If you need to broadcast a message to multiple servers, you can look into
> multicast or broadcast messaging, but that's for UDP.
>
>
>
> As for sending a message to all currently connected clients, I'm not
> sure.. I'll have to think on how to do that and whether it's a good idea.
> Theoretically it is possible.
>
>
>
> Keep in mind that OSC is typically a UDP protocol and is designed around
> one-way messaging.  Liblo incidentally supports responses, but it's common
> for UDP protocols to be unidirectional.
>
> On the TCP side, often clients will make a connection, send a message,
> *maybe* wait for a response, and then close the connection.  Long-lived
> connections are more rarely used; but if they are, they shouldn't *depend*
> on the connection state.
>
>
>
> Hope this helps,
>
> Steve
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Re: [liblo] how to connect to a liblo TCP OSC server?

[Aigner R. <rol...@fh...>]

Hi Steve,

Thanks for your detailed reply, that did indeed help. The cause for confusion is in fact terminology and what I would associate with the term “server” (i.e. a device providing data) and that the notation is apparently different here (a device consuming data).

Also thanks a ton for providing liblo as free software, it’s real helpful!

Best,
Roland



From: Stephen Sinclair <rad...@gm...>
Sent: Tuesday, August 4, 2020 6:16 PM
To: liblo development list <lib...@li...>
Subject: Re: [liblo] how to connect to a liblo TCP OSC server?

Hi Roland,


On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland <rol...@fh...<mailto:rol...@fh...>> wrote:

However I struggle to figure out how I would connect a client to this server, i.e. what the code should look like for a client receiving the data sent by this server.

I'm not sure if your concept of client and server is mixed up here?  In OSC it is the client sending data to the server.


Documentation and sample code leave me scratching my head, I tried to figure out by checking the library source code, but so far I failed to understand. From the fact that lo_send_message_from requires a target address I infer that I would have to iterate through all connected clients and sent to the respective sockets manually.

You can get a target address by creating one, if you know the destination, or you can get the sender's address from inside a message handler:

    lo_address a = lo_message_get_source(data);
    lo_send(a, "/hi", "i", 3);


But how do I know when a client connection gets accepted?

Who knows?  The server knows because a handler is being executed.  The client only knows whether the send failed.



So, summarizing, my two remaining questions are

  1.  how do I connect a client to the server?

Your code (which I snipped from the message, apologies) is correct.  You just create a server and specify LO_TCP for its protocol, and a client specifying LO_TCP for its protocol.  Then the client should be able to make a connection to the server and send it a message.




  1.  how do I know what clients are currently connected that I would have to send my packages to?

Hm, I don't think liblo provides a way to enumerate the current client connections.. could be interesting, but it's not too usual to want to broadcast to a random client.  Usually messages from the server are limited to _responses_ that are sent during message handlers, and in that case you can get the response destination using lo_message_get_source as I outlined above.

Note that if your client wants to receive a response... actually it cannot, it needs to set up a server to receive the response, and use lo_send_from, specifying that server.  That's how the destination server can find where to send responses back to.  So for bidirectional messaging, each side has a server.

If you need to broadcast a message to multiple servers, you can look into multicast or broadcast messaging, but that's for UDP.

As for sending a message to all currently connected clients, I'm not sure.. I'll have to think on how to do that and whether it's a good idea.  Theoretically it is possible.

Keep in mind that OSC is typically a UDP protocol and is designed around one-way messaging.  Liblo incidentally supports responses, but it's common for UDP protocols to be unidirectional.
On the TCP side, often clients will make a connection, send a message, maybe wait for a response, and then close the connection.  Long-lived connections are more rarely used; but if they are, they shouldn't depend on the connection state.

Hope this helps,
Steve

Re: [liblo] how to connect to a liblo TCP OSC server?

[Stephen S. <rad...@gm...>]

Hi Roland,


On Tue, Aug 4, 2020 at 1:36 PM Aigner Roland <rol...@fh...>
wrote:

> However I struggle to figure out how I would connect a client to this
> server, i.e. what the code should look like for a client receiving the data
> sent by this server.
>

I'm not sure if your concept of client and server is mixed up here?  In OSC
it is the client sending data to the server.

Documentation and sample code leave me scratching my head, I tried to
> figure out by checking the library source code, but so far I failed to
> understand. From the fact that lo_send_message_from requires a target
> address I infer that I would have to iterate through all connected clients
> and sent to the respective sockets manually.
>

You can get a target address by creating one, if you know the destination,
or you can get the sender's address from inside a message handler:

    lo_address a = lo_message_get_source(data);

    lo_send(a, "/hi", "i", 3);


> But how do I know when a client connection gets accepted?
>

Who knows?  The server knows because a handler is being executed.  The
client only knows whether the send failed.



> So, summarizing, my two remaining questions are
>
>    1. how do I connect a client to the server?
>
>
Your code (which I snipped from the message, apologies) is correct.  You
just create a server and specify LO_TCP for its protocol, and a client
specifying LO_TCP for its protocol.  Then the client should be able to make
a connection to the server and send it a message.



>
>
>    1. how do I know what clients are currently connected that I would
>    have to send my packages to?
>
>
Hm, I don't think liblo provides a way to enumerate the current client
connections.. could be interesting, but it's not too usual to want to
broadcast to a random client.  Usually messages from the server are limited
to _responses_ that are sent during message handlers, and in that case you
can get the response destination using lo_message_get_source as I outlined
above.

Note that if your *client* wants to receive a response... actually it
cannot, it needs to set up a *server* to receive the response, and use
lo_send_from, specifying that server.  That's how the destination server
can find where to send responses back to.  So for bidirectional messaging,
each side has a server.

If you need to broadcast a message to multiple servers, you can look into
multicast or broadcast messaging, but that's for UDP.

As for sending a message to all currently connected clients, I'm not sure..
I'll have to think on how to do that and whether it's a good idea.
Theoretically it is possible.

Keep in mind that OSC is typically a UDP protocol and is designed around
one-way messaging.  Liblo incidentally supports responses, but it's common
for UDP protocols to be unidirectional.
On the TCP side, often clients will make a connection, send a message,
*maybe* wait for a response, and then close the connection.  Long-lived
connections are more rarely used; but if they are, they shouldn't *depend*
on the connection state.

Hope this helps,
Steve

[liblo] how to connect to a liblo TCP OSC server?

[Aigner R. <rol...@fh...>]

Hi everyone,



I'm using the lowlevel API with UDP for unidirectional OSC for some time now and for my current use case I'm trying now to switch to TCP. However, I'm having trouble understanding how to use the library. The example_tcp_echo_server demonstrates how to set up a server and I tried to replicate this. Basically, the way I got it, I have to do this:



//setup server to listen at localhost:7000

_tcpThread = lo_server_thread_new_with_proto( "7000", LO_TCP, errorHandler );

_tcpServer = lo_server_thread_get_server( _tcpThread );

lo_server_thread_start( _tcpThread );



//send to client at localhost:7001

_address = lo_address_new_with_proto( LO_TCP, "127.0.0.1", "7001" );

lo_send_message_from( _address, _tcpServer, "/test", message );



However I struggle to figure out how I would connect a client to this server, i.e. what the code should look like for a client receiving the data sent by this server. Documentation and sample code leave me scratching my head, I tried to figure out by checking the library source code, but so far I failed to understand. From the fact that lo_send_message_from requires a target address I infer that I would have to iterate through all connected clients and sent to the respective sockets manually. But how do I know when a client connection gets accepted? So, summarizing, my two remaining questions are

  1.  how do I connect a client to the server?
  2.  how do I know what clients are currently connected that I would have to send my packages to?

Thanks,

Roland

Re: [liblo] Android Anyone?

[Stephen S. <rad...@gm...>]

Okay Android + Qt/QML, that's good to know.. I'll check out this use
case. Thanks for the process notes.

By the way I think you may not be registered for the mailing list, as
I keep having to approve your posts.
(Not a problem, just letting you know.)

cheers,
Steve

On Fri, Apr 17, 2020 at 1:36 PM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen,
>
> As I said, I'm new to Android, but I have a good idea of how I'll structure our "real project". And in that structure, your build script is fine for "production". We may even be done with it. That's because I intend to include only the liblo.so library file in the real project.
>
> Loading a fresh copy of the NDK only added about two minutes to the build. That's not much of a price for the assurance that you have the correct, unmolested version.
>
> Your right in that I did not find "master". I attempted to build 0.31, and only now do I see that "master" branch in sourceforge. I'm not very familiar with sourceforge (although I should be).
>
> As far as the "standard" way to include liblo into the project, my understanding is that all we need to do is have a import statement for the library file in the MainActivity.class file. The library will be included in the .APK file, and installed if it isn't already. But, of course, we haven't gotten there yet, so I can't be certain.
>
> Then we call the library through a C++ wrapper that makes liblo appear as an object to Qt and QML.
>
> mark
>
>
>
> -----Original Message-----
> From: Stephen Sinclair [mailto:rad...@gm...]
> Sent: Friday, April 17, 2020 1:04 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
>
> Great that you had some success!
>
> Yes sorry I only made bare minimum effort to try to use the
> already-installed "ndk-build" instead of downloading the NDK, if it's
> already available on $PATH, but it probably doesn't work very
> generally. For now I just wanted to make sure it passed some CI
> testing at least.
>
> Suggestions welcome!  Although, I wouldn't expect android_build.sh to
> be "used in production", it's just supposed to be an example of how to
> get it to work.  And for CI testing.  I assume in a "real project"
> you'd install liblo as a part of your Android project build, or
> something along those lines, not sure -- I haven't done Android
> development in a few years.  Maybe there is a more standard way by now
> to distribute native-compiled libraries for Android Studio.
>
> The two errors you mention sound like you weren't working from
> "master", not sure what happened there but again, if you have any
> suggestions or bug reports feel free to post about them here or in
> github issues.
>
> regards,
> Steve
>
> On Fri, Apr 17, 2020 at 9:57 AM Mark Hotchkiss <Ma...@re...> wrote:
> >
> > Hi Stephen,
> >
> > Success. But not without some confusion (I'm easily confused). Here is how it went. Sorry if it's rather long.
> >
> > When I first ran the script, it did not detect my installed NDK and downloaded another copy. It surprised me, but after looking at why (that it expects for it to be in the liblo project directory), I decided that that was the best way to do it. My reasoning was 1) it will always use the version of the NDK that the build script expects, 2) other possibly incompatible configurations of the NDK that might exist on the system won't cause the build to fail, and 3) the build script will not be outdated by future releases of the NDK, as long as r21 remains available. And it doesn't take long to load, and only need to load the first time. Based on all that, I now think that Gradle is unnecessary.
>
> >
> > Having said that, the build failed anyway.
> >
> > The error I had was that the "index" function was missing. Having seen your commit for that issue, I assumed that I was trying to build the wrong version. After a few tries with other versions, I could not get rid of the error, so I simply replaced the server.c file with your new one. Then that error was gone and I got the other error, the multicast_iface change. But by then I knew what to do.
>
> >
> > So everything built fine and I now have a liblo.so file. I will link it in with an application tomorrow, and then try to plug it into the Qt framework. I will let you know how it goes.
>
> >
> > Mucho thanks,
> > mark
> >
> >
> >
> > -----Original Message-----
> > From: Stephen Sinclair [mailto:rad...@gm...]
> > Sent: Thursday, April 16, 2020 4:04 AM
> > To: liblo development list
> > Subject: Re: [liblo] Android Anyone?
> >
> >
> > Ok I can look into gradle from the command line, I simply followed
> > instructions I found for using the NDK from the command line which
> > indicated ndk-build.  I was quite happy to find something that didn't
> > require also downloading Android Studio.  Anyways, I'll see if I can
> > find more up to date information, thanks.
> >
> > Steve
> >
> > On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...> wrote:
> > >
> > > Hi Stephen  and Fernando,
> > >
> > > This is great !
> > >
> > > I have not run it yet (I'm locked out of the lab for cleaning) but I looked at the script and I like it. The fact that it uses the most recent NDK and Clang satisfies my client's requirements (I think). If it used Gradle instead of ndk-build, it would be perfect. The NDK is moving toward Gradle, and some fear that ndk-build may soon be deprecated. I doubt it though, and if it becomes an issue I can make those changes.
>
> >
> > >
> > > Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is rather narrow, but I see no reason that it wouldn't run on any distribution that runs the NDK.
>
> >
> > >
> > > Thanks so much for this. I will let you know the results in a few hours.
> > >
> > > mark
> > >
> > > -----Original Message-----
> > > From: Fernando Carello [mailto:fca...@gm...]
> > > Sent: Wednesday, April 15, 2020 3:59 AM
> > > To: liblo development list
> > > Subject: Re: [liblo] Android Anyone?
> > >
> > > Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it download the Android NDK):
> > >
> > > ~/src/liblo/libs/arm64-v8a$ file liblo.so
> > > liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1, stripped
>
> >
> > >
> > > I can't test it within a real Android app, but it should work straight away.
> > >
> > > Fernando
> > >
> > >
> > > Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair <rad...@gm...> ha scritto:
> > >>
> > >> Hi Fernando and Mark,
> > >>
> > >> What do you think of this method?
> > >>
> > >> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
> > >> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
> > >>
> > >> Basically, it downloads NDK 21, then runs automake to generate
> > >> config.h and lo.h, and then builds liblo using ndk-build.
> > >>
> > >> If this works for you, I'll update the README.
> > >>
> > >> regards,
> > >> Steve
> > >>
> > >> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...> wrote:
> > >> >
> > >> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
> > >> > The newer NDKs seem to miss some stuff: not only "true" GCC but some includes too.
> > >> > Of course if you would succeed building with the newest NDK, that would be absolutely great!!
> > >> > Best of luck. Very interested in your Android client app too!
> > >> > Fernando
> > >> >
> > >> >
> > >> >
> > >> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss <Ma...@re...> ha scritto:
> > >> >>
> > >> >> Thanks so much Fernando.
> > >> >>
> > >> >> Today is a "paperwork" day, so I might get to testing that late tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so I will need to load r14b first. But I suspect that version was the magic that I was missing.
>
> >
> > >> >>
> > >> >> Of course, my goal will be to build it with the latest SDK/NDK version.
> > >> >>
> > >> >> mark
> > >> >>
> > >> >> -----Original Message-----
> > >> >> From: Fernando Carello [mailto:fca...@gm...]
> > >> >> Sent: Friday, April 10, 2020 2:35 PM
> > >> >> To: liblo development list
> > >> >> Subject: Re: [liblo] Android Anyone?
> > >> >>
> > >> >> Oh I need to clear that you have to build one version at a time.
> > >> >> So let's say you first build Android 32 bit library: "source ./android_configure_armeabiv7.sh", make clean, configure, make etc.
>
> >
> > >> >> Copy the resulting 32 bit .so somewhere safe (or it will be overwritten).
> > >> >> Then build the 64 bit version: "source ./android_configure_arm64.sh", make clean and so on.
> > >> >>
> > >> >>
> > >> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello <fca...@gm...> ha scritto:
> > >> >>>
> > >> >>> Excellent.
> > >> >>>
> > >> >>> I uploaded the (configured and built) source tree on Dropbox for the moment (I'm sure github would be better but I don't have an account and am a total newbie vs git), along with the cross-compile configuring script I use.
>
> >
> > >> >>>
> > >> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did not try to build arm64 version of liblo):
> > >> >>> https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_scripts.zip?dl=0
> > >> >>>
> > >> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of the source tree (from liblo-0.31/src/.libs)
> > >> >>> https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=0
> > >> >>>
> > >> >>> Rough procedure:
> > >> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
> > >> >>> https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?hl=sr
> > >> >>>
> > >> >>> Unpack it somewhere; mine is simply in
> > >> >>>
> > >> >>> /home/fernando/android-ndk-r14b
> > >> >>> symlink:
> > >> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
> > >> >>>
> > >> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as indicated in the script source.
> > >> >>> Run the script (as current user, no need to sudo) using source (example: "source ./android_configure_armeabiv7.sh").
>
> >
> > >> >>> The script will copy some files, create some links and set some variables to enable cross-compiling for Android.
>
> > >> >>> Then move into liblo source, make clean, make distclean, run "./configure --host=x86_64-pc-linux-gnu", run make.
>
> > >> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under "src/.libs"
> > >> >>>
> > >> >>> That's all: let me know if I can be of further help.
> > >> >>>
> > >> >>> All the best,
> > >> >>> Fernando
> > >> >>>
> > >> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss <Ma...@re...> ha scritto:
> > >> >>>>
> > >> >>>> Fernando, that's not good news, it's GREAT news.
> > >> >>>>
> > >> >>>> I'm still perusing what you posted earlier, so there is still some that I don't understand. But if you can let me know 1) what tools I need, and 2) the rough procedure to build, I will test it here and try to refine it.
>
> >
> > >> >>>>
> > >> >>>> I can also look into any multicast issues on Android, and if multicast is really not possible on Android, then conditionally leave it out of testlo. Depending on how multicast behaves if you try to use it on Android (can it crash the app?), we may need to update the source.
>
> >
> > >> >>>>
> > >> >>>> What is the best way to exchange the build code?
> > >> >>>>
> > >> >>>> mark
> > >> >>>>
> > >> >>>> -----Original Message-----
> > >> >>>> From: Fernando Carello [mailto:fca...@gm...]
> > >> >>>> Sent: Friday, April 10, 2020 1:35 PM
> > >> >>>> To: liblo development list
> > >> >>>> Subject: Re: [liblo] Android Anyone?
> > >> >>>>
> > >> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if testlo failed:
> > >> >>>>
> > >> >>>> --
> > >> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
> > >> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/, with debug_info, not stripped
>
> >
> > >> >>>> --
> > >> >>>>
> > >> >>>> I *think* that "testlo" wants to test the multicast interface, even if "configure" stated there isn't one on Android.
>
> >
> > >> >>>> So one could either fix testlo (preferred), or for the moment disable the multicast interface test and call it a day.
>
> >
> > >> >>>>
> > >> >>>> Mark, let me know if I can be of further help.
> > >> >>>> I could:
> > >> >>>> - provide the Android liblo.so library I just built (32 bit only at the moment)
> > >> >>>> - provide (rough) directions to install and configure the needed cross-compilation tools
> > >> >>>>
> > >> >>>> Fernando
> > >> >>>>
> > >> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss <Ma...@re...> ha scritto:
> > >> >>>>>
> > >> >>>>> Hi Fernando and Stephen,
> > >> >>>>>
> > >> >>>>> Much thanks for the quick replies, and also for the speedy investigation into my problem. I will study those logs and links, and will have some questions, I'm sure.
>
> >
> > >> >>>>>
> > >> >>>>> When it comes Android, I am as new as it gets. I've only installed the SDK and NDK last weekend, and didn't even consider using Android two weeks ago. I have a steep learning curve, but that has never stopped me before.
>
> >
> > >> >>>>>
> > >> >>>>> Thanks again for the help.
> > >> >>>>>
> > >> >>>>> mark
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> -----Original Message-----
> > >> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
> > >> >>>>> Sent: Friday, April 10, 2020 8:13 AM
> > >> >>>>> To: liblo development list
> > >> >>>>> Subject: Re: [liblo] Android Anyone?
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> Hi Mark,
> > >> >>>>>
> > >> >>>>> Fernando is on the right track.  Unfortunately I can't install Android
> > >> >>>>> NDK and make it work for you at the moment, but in principle it
> > >> >>>>> should.  I'd welcome any contribution to update the Android build
> > >> >>>>> procedure.
> > >> >>>>>
> > >> >>>>> I am not sure why --host is failing for you Fernando.  I just tried
> > >> >>>>> building with the only cross-compiler I have installed on my system,
> > >> >>>>> MingW, and it configured and built just fine without trying to execute
> > >> >>>>> the compiler output. Normally it should not do that as long as --host
> > >> >>>>> and --build are not the same:
> > >> >>>>>
> > >> >>>>> https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html
> > >> >>>>>
> > >> >>>>> It looks like Travis has some Android NDK things available, so perhaps
> > >> >>>>> I can get some CI configuration working to test an Android build:
> > >> >>>>>
> > >> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
> > >> >>>>>
> > >> >>>>> Steve
> > >> >>>>>
> > >> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello <fca...@gm...> wrote:
> > >> >>>>> >
> > >> >>>>> > Hi Mark,
> > >> >>>>> > just my 2 cents (newbie here).
> > >> >>>>> >
> > >> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for other reasons (building OpenSSL).
> > >> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9; I can build for 32-bit and 64-bit Android ARM targets.
>
> >
> > >> >>>>>
> > >> >>>>> >
> > >> >>>>> > Problem is, liblo's "configure" does not seem to like my environment; it pretends to run a cross-compiled executable, and obviously fails.
>
> >
> > >> >>>>>
> > >> >>>>> >
> > >> >>>>> > Specifically:
> > >> >>>>> >
> > >> >>>>> > ----
> > >> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
> > >> >>>>> > checking whether build environment is sane... yes
> > >> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
> > >> >>>>> > checking for gawk... gawk
> > >> >>>>> > checking whether make sets $(MAKE)... yes
> > >> >>>>> > checking whether make supports nested variables... yes
> > >> >>>>> > checking whether to enable maintainer-specific portions of Makefiles... no
> > >> >>>>> > checking whether make supports nested variables... (cached) yes
> > >> >>>>> > checking for gcc... /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64  --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >
> > >> >>>>>
> > >> >>>>> > checking whether the C compiler works... yes
> > >> >>>>> > checking for C compiler default output file name... a.out
> > >> >>>>> > checking for suffix of executables...
> > >> >>>>> > checking whether we are cross compiling... configure: error: in `/home/fernando/src/liblo-0.31':
> > >> >>>>> > configure: error: cannot run C compiled programs.
> > >> >>>>> > If you meant to cross compile, use `--host'.
> > >> >>>>> > See `config.log' for more details
> > >> >>>>> >
> > >> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
> > >> >>>>> >
> > >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
> > >> >>>>> > configure: error: missing argument to --host-alias
> > >> >>>>> > ---
> > >> >>>>> >
> > >> >>>>> > For completeness, my $CC:
> > >> >>>>> >
> > >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
> > >> >>>>> > /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64 --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >
> > >> >>>>>
> > >> >>>>> >
> > >> >>>>> > My config.log is attached.
> > >> >>>>> >
> > >> >>>>> > Hope this helps.
> > >> >>>>> > Please note, I'm no way an Android expert! :)
> > >> >>>>> >
> > >> >>>>> >
> > >> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss <Ma...@re...> ha scritto:
> > >> >>>>> >>
> > >> >>>>> >> Hello Stephen, other developers, et.al.
> > >> >>>>> >>
> > >> >>>>> >> Thanks so much for keeping this project moving forward. I'm hoping to contribute, although in a small way.
>
> > >> >>>>> >>
> > >> >>>>> >> I first used liblo in 2015 for an augmented-reality project. That used it to communicate position data between Linux computers, and it worked very well.
>
> >
> > >> >>>>>
> > >> >>>>> >>
> > >> >>>>> >> Now I'm using it in a rather large project, where multiple user-interface controllers are communicating with the main communications processor in a robotic system. I'm using multiple ports (five, at the moment), with each device containing multiple servers and also sending to multiple servers. It is working well when all of the devices are Linux.
>
> >
> > >> >>>>>
> > >> >>>>> >>
> > >> >>>>> >> But we need tablets for the UI devices, and the Linux tablet that we tried fell on its face (BQ Aquaris M10), and we can find no others. So we have resigned ourselves to having to use Android tablets. So the task now entails porting the application and libraries to the Android SDK and NDK.
>
> >
> > >> >>>>>
> > >> >>>>> >>
> > >> >>>>> >> It appears that the Android build procedure included in the liblo project hasn't worked since gcc was removed from the NDK some years back (the SDK now uses clang). Searching the web, nobody ever asks about liblo on Android. The last mention of Android on this mail list is six years ago. So I have a few questions:
>
> >
> > >> >>>>>
> > >> >>>>> >>
> > >> >>>>> >> 1) Has anybody ever used liblo on Android?
> > >> >>>>> >> 2) Are there any known reasons why it might not work?
> > >> >>>>> >> 3) If not, does anyone have any idea how to build liblo with the current Android NDK?
> > >> >>>>> >>
> > >> >>>>> >> I am new to Android development, although I've been doing embedded development for decades. Unless someone knows of a reason why it won't work, I'm willing to build liblo for Android and create a new Android build script (new, until an NDK update breaks it again). A minor contribution, maybe, but a key step for our project.
>
> >
> > >> >>>>>
> > >> >>>>> >>
> > >> >>>>> >> Last question: what do you think?
> > >> >>>>> >>
> > >> >>>>> >> Thanks,
> > >> >>>>> >> Mark
> > >> >>>>> >>
> > >> >>>>> >> -------------------
> > >> >>>>> >> Mark Hotchkiss
> > >> >>>>> >> Louma Inc.
> > >> >>>>> >> 4351 Clark Avenue
> > >> >>>>> >> Long Beach, CA 90808
> > >> >>>>> >> phone: (562) 230-1080
> > >> >>>>> >> email:  ma...@re...
> > >> >>>>> >>
> > >> >>>>> >>
> > >> >>>>> >> _______________________________________________
> > >> >>>>> >> liblo-devel mailing list
> > >> >>>>> >> lib...@li...
> > >> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >>>>> >
> > >> >>>>> > _______________________________________________
> > >> >>>>> > liblo-devel mailing list
> > >> >>>>> > lib...@li...
> > >> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> _______________________________________________
> > >> >>>>> liblo-devel mailing list
> > >> >>>>> lib...@li...
> > >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >>>>>
> > >> >>>>> _______________________________________________
> > >> >>>>> liblo-devel mailing list
> > >> >>>>> lib...@li...
> > >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >>>>
> > >> >>>> _______________________________________________
> > >> >>>> liblo-devel mailing list
> > >> >>>> lib...@li...
> > >> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >>
> > >> >> _______________________________________________
> > >> >> liblo-devel mailing list
> > >> >> lib...@li...
> > >> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >> >
> > >> > _______________________________________________
> > >> > liblo-devel mailing list
> > >> > lib...@li...
> > >> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >>
> > >>
> > >> _______________________________________________
> > >> liblo-devel mailing list
> > >> lib...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> > >
> > > _______________________________________________
> > > liblo-devel mailing list
> > > lib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> >
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] Android Anyone?

[Mark H. <Ma...@re...>]

Hi Stephen,

As I said, I'm new to Android, but I have a good idea of how I'll structure
our "real project". And in that structure, your build script is fine for
"production". We may even be done with it. That's because I intend to
include only the liblo.so library file in the real project.

Loading a fresh copy of the NDK only added about two minutes to the build.
That's not much of a price for the assurance that you have the correct,
unmolested version.

Your right in that I did not find "master". I attempted to build 0.31, and
only now do I see that "master" branch in sourceforge. I'm not very familiar
with sourceforge (although I should be).

As far as the "standard" way to include liblo into the project, my
understanding is that all we need to do is have a import statement for the
library file in the MainActivity.class file. The library will be included in
the .APK file, and installed if it isn't already. But, of course, we haven't
gotten there yet, so I can't be certain.

Then we call the library through a C++ wrapper that makes liblo appear as an
object to Qt and QML.

mark



-----Original Message-----
From: Stephen Sinclair [mailto:rad...@gm...]
Sent: Friday, April 17, 2020 1:04 AM
To: liblo development list
Subject: Re: [liblo] Android Anyone?


Great that you had some success!

Yes sorry I only made bare minimum effort to try to use the
already-installed "ndk-build" instead of downloading the NDK, if it's
already available on $PATH, but it probably doesn't work very
generally. For now I just wanted to make sure it passed some CI
testing at least.

Suggestions welcome!  Although, I wouldn't expect android_build.sh to
be "used in production", it's just supposed to be an example of how to
get it to work.  And for CI testing.  I assume in a "real project"
you'd install liblo as a part of your Android project build, or
something along those lines, not sure -- I haven't done Android
development in a few years.  Maybe there is a more standard way by now
to distribute native-compiled libraries for Android Studio.

The two errors you mention sound like you weren't working from
"master", not sure what happened there but again, if you have any
suggestions or bug reports feel free to post about them here or in
github issues.

regards,
Steve

On Fri, Apr 17, 2020 at 9:57 AM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen,
>
> Success. But not without some confusion (I'm easily confused). Here is how
it went. Sorry if it's rather long.
>
> When I first ran the script, it did not detect my installed NDK and
downloaded another copy. It surprised me, but after looking at why (that it
expects for it to be in the liblo project directory), I decided that that
was the best way to do it. My reasoning was 1) it will always use the
version of the NDK that the build script expects, 2) other possibly
incompatible configurations of the NDK that might exist on the system won't
cause the build to fail, and 3) the build script will not be outdated by
future releases of the NDK, as long as r21 remains available. And it doesn't
take long to load, and only need to load the first time. Based on all that,
I now think that Gradle is unnecessary.
>
> Having said that, the build failed anyway.
>
> The error I had was that the "index" function was missing. Having seen
your commit for that issue, I assumed that I was trying to build the wrong
version. After a few tries with other versions, I could not get rid of the
error, so I simply replaced the server.c file with your new one. Then that
error was gone and I got the other error, the multicast_iface change. But by
then I knew what to do.
>
> So everything built fine and I now have a liblo.so file. I will link it in
with an application tomorrow, and then try to plug it into the Qt framework.
I will let you know how it goes.
>
> Mucho thanks,
> mark
>
>
>
> -----Original Message-----
> From: Stephen Sinclair [mailto:rad...@gm...]
> Sent: Thursday, April 16, 2020 4:04 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
>
> Ok I can look into gradle from the command line, I simply followed
> instructions I found for using the NDK from the command line which
> indicated ndk-build.  I was quite happy to find something that didn't
> require also downloading Android Studio.  Anyways, I'll see if I can
> find more up to date information, thanks.
>
> Steve
>
> On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...>
wrote:
> >
> > Hi Stephen  and Fernando,
> >
> > This is great !
> >
> > I have not run it yet (I'm locked out of the lab for cleaning) but I
looked at the script and I like it. The fact that it uses the most recent
NDK and Clang satisfies my client's requirements (I think). If it used
Gradle instead of ndk-build, it would be perfect. The NDK is moving toward
Gradle, and some fear that ndk-build may soon be deprecated. I doubt it
though, and if it becomes an issue I can make those changes.
>
> >
> > Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is
rather narrow, but I see no reason that it wouldn't run on any distribution
that runs the NDK.
>
> >
> > Thanks so much for this. I will let you know the results in a few hours.
> >
> > mark
> >
> > -----Original Message-----
> > From: Fernando Carello [mailto:fca...@gm...]
> > Sent: Wednesday, April 15, 2020 3:59 AM
> > To: liblo development list
> > Subject: Re: [liblo] Android Anyone?
> >
> > Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it
download the Android NDK):
> >
> > ~/src/liblo/libs/arm64-v8a$ file liblo.so
> > liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV),
dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1,
stripped
>
> >
> > I can't test it within a real Android app, but it should work straight
away.
> >
> > Fernando
> >
> >
> > Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair
<rad...@gm...> ha scritto:
> >>
> >> Hi Fernando and Mark,
> >>
> >> What do you think of this method?
> >>
> >> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
> >> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
> >>
> >> Basically, it downloads NDK 21, then runs automake to generate
> >> config.h and lo.h, and then builds liblo using ndk-build.
> >>
> >> If this works for you, I'll update the README.
> >>
> >> regards,
> >> Steve
> >>
> >> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...>
wrote:
> >> >
> >> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
> >> > The newer NDKs seem to miss some stuff: not only "true" GCC but some
includes too.
> >> > Of course if you would succeed building with the newest NDK, that
would be absolutely great!!
> >> > Best of luck. Very interested in your Android client app too!
> >> > Fernando
> >> >
> >> >
> >> >
> >> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss
<Ma...@re...> ha scritto:
> >> >>
> >> >> Thanks so much Fernando.
> >> >>
> >> >> Today is a "paperwork" day, so I might get to testing that late
tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so
I will need to load r14b first. But I suspect that version was the magic
that I was missing.
>
> >> >>
> >> >> Of course, my goal will be to build it with the latest SDK/NDK
version.
> >> >>
> >> >> mark
> >> >>
> >> >> -----Original Message-----
> >> >> From: Fernando Carello [mailto:fca...@gm...]
> >> >> Sent: Friday, April 10, 2020 2:35 PM
> >> >> To: liblo development list
> >> >> Subject: Re: [liblo] Android Anyone?
> >> >>
> >> >> Oh I need to clear that you have to build one version at a time.
> >> >> So let's say you first build Android 32 bit library: "source
./android_configure_armeabiv7.sh", make clean, configure, make etc.
>
> >> >> Copy the resulting 32 bit .so somewhere safe (or it will be
overwritten).
> >> >> Then build the 64 bit version: "source
./android_configure_arm64.sh", make clean and so on.
> >> >>
> >> >>
> >> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello
<fca...@gm...> ha scritto:
> >> >>>
> >> >>> Excellent.
> >> >>>
> >> >>> I uploaded the (configured and built) source tree on Dropbox for
the moment (I'm sure github would be better but I don't have an account and
am a total newbie vs git), along with the cross-compile configuring script I
use.
>
> >> >>>
> >> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did
not try to build arm64 version of liblo):
> >> >>>
https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_script
s.zip?dl=0
> >> >>>
> >> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of
the source tree (from liblo-0.31/src/.libs)
> >> >>>
https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=
0
> >> >>>
> >> >>> Rough procedure:
> >> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
> >> >>>
https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?h
l=sr
> >> >>>
> >> >>> Unpack it somewhere; mine is simply in
> >> >>>
> >> >>> /home/fernando/android-ndk-r14b
> >> >>> symlink:
> >> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
> >> >>>
> >> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as
indicated in the script source.
> >> >>> Run the script (as current user, no need to sudo) using source
(example: "source ./android_configure_armeabiv7.sh").
>
> >> >>> The script will copy some files, create some links and set some
variables to enable cross-compiling for Android.
> >> >>> Then move into liblo source, make clean, make distclean, run
"./configure --host=x86_64-pc-linux-gnu", run make.
> >> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under
"src/.libs"
> >> >>>
> >> >>> That's all: let me know if I can be of further help.
> >> >>>
> >> >>> All the best,
> >> >>> Fernando
> >> >>>
> >> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss
<Ma...@re...> ha scritto:
> >> >>>>
> >> >>>> Fernando, that's not good news, it's GREAT news.
> >> >>>>
> >> >>>> I'm still perusing what you posted earlier, so there is still some
that I don't understand. But if you can let me know 1) what tools I need,
and 2) the rough procedure to build, I will test it here and try to refine
it.
>
> >> >>>>
> >> >>>> I can also look into any multicast issues on Android, and if
multicast is really not possible on Android, then conditionally leave it out
of testlo. Depending on how multicast behaves if you try to use it on
Android (can it crash the app?), we may need to update the source.
>
> >> >>>>
> >> >>>> What is the best way to exchange the build code?
> >> >>>>
> >> >>>> mark
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Fernando Carello [mailto:fca...@gm...]
> >> >>>> Sent: Friday, April 10, 2020 1:35 PM
> >> >>>> To: liblo development list
> >> >>>> Subject: Re: [liblo] Android Anyone?
> >> >>>>
> >> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if
testlo failed:
> >> >>>>
> >> >>>> --
> >> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
> >> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1
(SYSV), dynamically linked, interpreter /system/, with debug_info, not
stripped
>
> >> >>>> --
> >> >>>>
> >> >>>> I *think* that "testlo" wants to test the multicast interface,
even if "configure" stated there isn't one on Android.
>
> >> >>>> So one could either fix testlo (preferred), or for the moment
disable the multicast interface test and call it a day.
>
> >> >>>>
> >> >>>> Mark, let me know if I can be of further help.
> >> >>>> I could:
> >> >>>> - provide the Android liblo.so library I just built (32 bit only
at the moment)
> >> >>>> - provide (rough) directions to install and configure the needed
cross-compilation tools
> >> >>>>
> >> >>>> Fernando
> >> >>>>
> >> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss
<Ma...@re...> ha scritto:
> >> >>>>>
> >> >>>>> Hi Fernando and Stephen,
> >> >>>>>
> >> >>>>> Much thanks for the quick replies, and also for the speedy
investigation into my problem. I will study those logs and links, and will
have some questions, I'm sure.
>
> >> >>>>>
> >> >>>>> When it comes Android, I am as new as it gets. I've only
installed the SDK and NDK last weekend, and didn't even consider using
Android two weeks ago. I have a steep learning curve, but that has never
stopped me before.
>
> >> >>>>>
> >> >>>>> Thanks again for the help.
> >> >>>>>
> >> >>>>> mark
> >> >>>>>
> >> >>>>>
> >> >>>>> -----Original Message-----
> >> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
> >> >>>>> Sent: Friday, April 10, 2020 8:13 AM
> >> >>>>> To: liblo development list
> >> >>>>> Subject: Re: [liblo] Android Anyone?
> >> >>>>>
> >> >>>>>
> >> >>>>> Hi Mark,
> >> >>>>>
> >> >>>>> Fernando is on the right track.  Unfortunately I can't install
Android
> >> >>>>> NDK and make it work for you at the moment, but in principle it
> >> >>>>> should.  I'd welcome any contribution to update the Android build
> >> >>>>> procedure.
> >> >>>>>
> >> >>>>> I am not sure why --host is failing for you Fernando.  I just
tried
> >> >>>>> building with the only cross-compiler I have installed on my
system,
> >> >>>>> MingW, and it configured and built just fine without trying to
execute
> >> >>>>> the compiler output. Normally it should not do that as long as
--host
> >> >>>>> and --build are not the same:
> >> >>>>>
> >> >>>>>
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation
.html
> >> >>>>>
> >> >>>>> It looks like Travis has some Android NDK things available, so
perhaps
> >> >>>>> I can get some CI configuration working to test an Android build:
> >> >>>>>
> >> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
> >> >>>>>
> >> >>>>> Steve
> >> >>>>>
> >> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello
<fca...@gm...> wrote:
> >> >>>>> >
> >> >>>>> > Hi Mark,
> >> >>>>> > just my 2 cents (newbie here).
> >> >>>>> >
> >> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for
other reasons (building OpenSSL).
> >> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9;
I can build for 32-bit and 64-bit Android ARM targets.
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > Problem is, liblo's "configure" does not seem to like my
environment; it pretends to run a cross-compiled executable, and obviously
fails.
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > Specifically:
> >> >>>>> >
> >> >>>>> > ----
> >> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
> >> >>>>> > checking whether build environment is sane... yes
> >> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
> >> >>>>> > checking for gawk... gawk
> >> >>>>> > checking whether make sets $(MAKE)... yes
> >> >>>>> > checking whether make supports nested variables... yes
> >> >>>>> > checking whether to enable maintainer-specific portions of
Makefiles... no
> >> >>>>> > checking whether make supports nested variables... (cached) yes
> >> >>>>> > checking for gcc...
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >> >>>>>
> >> >>>>> > checking whether the C compiler works... yes
> >> >>>>> > checking for C compiler default output file name... a.out
> >> >>>>> > checking for suffix of executables...
> >> >>>>> > checking whether we are cross compiling... configure: error: in
`/home/fernando/src/liblo-0.31':
> >> >>>>> > configure: error: cannot run C compiled programs.
> >> >>>>> > If you meant to cross compile, use `--host'.
> >> >>>>> > See `config.log' for more details
> >> >>>>> >
> >> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
> >> >>>>> >
> >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
> >> >>>>> > configure: error: missing argument to --host-alias
> >> >>>>> > ---
> >> >>>>> >
> >> >>>>> > For completeness, my $CC:
> >> >>>>> >
> >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
> >> >>>>> >
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > My config.log is attached.
> >> >>>>> >
> >> >>>>> > Hope this helps.
> >> >>>>> > Please note, I'm no way an Android expert! :)
> >> >>>>> >
> >> >>>>> >
> >> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss
<Ma...@re...> ha scritto:
> >> >>>>> >>
> >> >>>>> >> Hello Stephen, other developers, et.al.
> >> >>>>> >>
> >> >>>>> >> Thanks so much for keeping this project moving forward. I'm
hoping to contribute, although in a small way.
> >> >>>>> >>
> >> >>>>> >> I first used liblo in 2015 for an augmented-reality project.
That used it to communicate position data between Linux computers, and it
worked very well.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> Now I'm using it in a rather large project, where multiple
user-interface controllers are communicating with the main communications
processor in a robotic system. I'm using multiple ports (five, at the
moment), with each device containing multiple servers and also sending to
multiple servers. It is working well when all of the devices are Linux.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> But we need tablets for the UI devices, and the Linux tablet
that we tried fell on its face (BQ Aquaris M10), and we can find no others.
So we have resigned ourselves to having to use Android tablets. So the task
now entails porting the application and libraries to the Android SDK and
NDK.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> It appears that the Android build procedure included in the
liblo project hasn't worked since gcc was removed from the NDK some years
back (the SDK now uses clang). Searching the web, nobody ever asks about
liblo on Android. The last mention of Android on this mail list is six years
ago. So I have a few questions:
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> 1) Has anybody ever used liblo on Android?
> >> >>>>> >> 2) Are there any known reasons why it might not work?
> >> >>>>> >> 3) If not, does anyone have any idea how to build liblo with
the current Android NDK?
> >> >>>>> >>
> >> >>>>> >> I am new to Android development, although I've been doing
embedded development for decades. Unless someone knows of a reason why it
won't work, I'm willing to build liblo for Android and create a new Android
build script (new, until an NDK update breaks it again). A minor
contribution, maybe, but a key step for our project.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> Last question: what do you think?
> >> >>>>> >>
> >> >>>>> >> Thanks,
> >> >>>>> >> Mark
> >> >>>>> >>
> >> >>>>> >> -------------------
> >> >>>>> >> Mark Hotchkiss
> >> >>>>> >> Louma Inc.
> >> >>>>> >> 4351 Clark Avenue
> >> >>>>> >> Long Beach, CA 90808
> >> >>>>> >> phone: (562) 230-1080
> >> >>>>> >> email:  ma...@re...
> >> >>>>> >>
> >> >>>>> >>
> >> >>>>> >> _______________________________________________
> >> >>>>> >> liblo-devel mailing list
> >> >>>>> >> lib...@li...
> >> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>> >
> >> >>>>> > _______________________________________________
> >> >>>>> > liblo-devel mailing list
> >> >>>>> > lib...@li...
> >> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>>
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> liblo-devel mailing list
> >> >>>>> lib...@li...
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> liblo-devel mailing list
> >> >>>>> lib...@li...
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> liblo-devel mailing list
> >> >>>> lib...@li...
> >> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>
> >> >> _______________________________________________
> >> >> liblo-devel mailing list
> >> >> lib...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >
> >> > _______________________________________________
> >> > liblo-devel mailing list
> >> > lib...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >>
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] Android Anyone?

[Stephen S. <rad...@gm...>]

Great that you had some success!

Yes sorry I only made bare minimum effort to try to use the
already-installed "ndk-build" instead of downloading the NDK, if it's
already available on $PATH, but it probably doesn't work very
generally. For now I just wanted to make sure it passed some CI
testing at least.

Suggestions welcome!  Although, I wouldn't expect android_build.sh to
be "used in production", it's just supposed to be an example of how to
get it to work.  And for CI testing.  I assume in a "real project"
you'd install liblo as a part of your Android project build, or
something along those lines, not sure -- I haven't done Android
development in a few years.  Maybe there is a more standard way by now
to distribute native-compiled libraries for Android Studio.

The two errors you mention sound like you weren't working from
"master", not sure what happened there but again, if you have any
suggestions or bug reports feel free to post about them here or in
github issues.

regards,
Steve

On Fri, Apr 17, 2020 at 9:57 AM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen,
>
> Success. But not without some confusion (I'm easily confused). Here is how it went. Sorry if it's rather long.
>
> When I first ran the script, it did not detect my installed NDK and downloaded another copy. It surprised me, but after looking at why (that it expects for it to be in the liblo project directory), I decided that that was the best way to do it. My reasoning was 1) it will always use the version of the NDK that the build script expects, 2) other possibly incompatible configurations of the NDK that might exist on the system won't cause the build to fail, and 3) the build script will not be outdated by future releases of the NDK, as long as r21 remains available. And it doesn't take long to load, and only need to load the first time. Based on all that, I now think that Gradle is unnecessary.
>
> Having said that, the build failed anyway.
>
> The error I had was that the "index" function was missing. Having seen your commit for that issue, I assumed that I was trying to build the wrong version. After a few tries with other versions, I could not get rid of the error, so I simply replaced the server.c file with your new one. Then that error was gone and I got the other error, the multicast_iface change. But by then I knew what to do.
>
> So everything built fine and I now have a liblo.so file. I will link it in with an application tomorrow, and then try to plug it into the Qt framework. I will let you know how it goes.
>
> Mucho thanks,
> mark
>
>
>
> -----Original Message-----
> From: Stephen Sinclair [mailto:rad...@gm...]
> Sent: Thursday, April 16, 2020 4:04 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
>
> Ok I can look into gradle from the command line, I simply followed
> instructions I found for using the NDK from the command line which
> indicated ndk-build.  I was quite happy to find something that didn't
> require also downloading Android Studio.  Anyways, I'll see if I can
> find more up to date information, thanks.
>
> Steve
>
> On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...> wrote:
> >
> > Hi Stephen  and Fernando,
> >
> > This is great !
> >
> > I have not run it yet (I'm locked out of the lab for cleaning) but I looked at the script and I like it. The fact that it uses the most recent NDK and Clang satisfies my client's requirements (I think). If it used Gradle instead of ndk-build, it would be perfect. The NDK is moving toward Gradle, and some fear that ndk-build may soon be deprecated. I doubt it though, and if it becomes an issue I can make those changes.
>
> >
> > Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is rather narrow, but I see no reason that it wouldn't run on any distribution that runs the NDK.
>
> >
> > Thanks so much for this. I will let you know the results in a few hours.
> >
> > mark
> >
> > -----Original Message-----
> > From: Fernando Carello [mailto:fca...@gm...]
> > Sent: Wednesday, April 15, 2020 3:59 AM
> > To: liblo development list
> > Subject: Re: [liblo] Android Anyone?
> >
> > Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it download the Android NDK):
> >
> > ~/src/liblo/libs/arm64-v8a$ file liblo.so
> > liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1, stripped
>
> >
> > I can't test it within a real Android app, but it should work straight away.
> >
> > Fernando
> >
> >
> > Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair <rad...@gm...> ha scritto:
> >>
> >> Hi Fernando and Mark,
> >>
> >> What do you think of this method?
> >>
> >> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
> >> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
> >>
> >> Basically, it downloads NDK 21, then runs automake to generate
> >> config.h and lo.h, and then builds liblo using ndk-build.
> >>
> >> If this works for you, I'll update the README.
> >>
> >> regards,
> >> Steve
> >>
> >> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...> wrote:
> >> >
> >> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
> >> > The newer NDKs seem to miss some stuff: not only "true" GCC but some includes too.
> >> > Of course if you would succeed building with the newest NDK, that would be absolutely great!!
> >> > Best of luck. Very interested in your Android client app too!
> >> > Fernando
> >> >
> >> >
> >> >
> >> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss <Ma...@re...> ha scritto:
> >> >>
> >> >> Thanks so much Fernando.
> >> >>
> >> >> Today is a "paperwork" day, so I might get to testing that late tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so I will need to load r14b first. But I suspect that version was the magic that I was missing.
>
> >> >>
> >> >> Of course, my goal will be to build it with the latest SDK/NDK version.
> >> >>
> >> >> mark
> >> >>
> >> >> -----Original Message-----
> >> >> From: Fernando Carello [mailto:fca...@gm...]
> >> >> Sent: Friday, April 10, 2020 2:35 PM
> >> >> To: liblo development list
> >> >> Subject: Re: [liblo] Android Anyone?
> >> >>
> >> >> Oh I need to clear that you have to build one version at a time.
> >> >> So let's say you first build Android 32 bit library: "source ./android_configure_armeabiv7.sh", make clean, configure, make etc.
>
> >> >> Copy the resulting 32 bit .so somewhere safe (or it will be overwritten).
> >> >> Then build the 64 bit version: "source ./android_configure_arm64.sh", make clean and so on.
> >> >>
> >> >>
> >> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello <fca...@gm...> ha scritto:
> >> >>>
> >> >>> Excellent.
> >> >>>
> >> >>> I uploaded the (configured and built) source tree on Dropbox for the moment (I'm sure github would be better but I don't have an account and am a total newbie vs git), along with the cross-compile configuring script I use.
>
> >> >>>
> >> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did not try to build arm64 version of liblo):
> >> >>> https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_scripts.zip?dl=0
> >> >>>
> >> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of the source tree (from liblo-0.31/src/.libs)
> >> >>> https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=0
> >> >>>
> >> >>> Rough procedure:
> >> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
> >> >>> https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?hl=sr
> >> >>>
> >> >>> Unpack it somewhere; mine is simply in
> >> >>>
> >> >>> /home/fernando/android-ndk-r14b
> >> >>> symlink:
> >> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
> >> >>>
> >> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as indicated in the script source.
> >> >>> Run the script (as current user, no need to sudo) using source (example: "source ./android_configure_armeabiv7.sh").
>
> >> >>> The script will copy some files, create some links and set some variables to enable cross-compiling for Android.
> >> >>> Then move into liblo source, make clean, make distclean, run "./configure --host=x86_64-pc-linux-gnu", run make.
> >> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under "src/.libs"
> >> >>>
> >> >>> That's all: let me know if I can be of further help.
> >> >>>
> >> >>> All the best,
> >> >>> Fernando
> >> >>>
> >> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss <Ma...@re...> ha scritto:
> >> >>>>
> >> >>>> Fernando, that's not good news, it's GREAT news.
> >> >>>>
> >> >>>> I'm still perusing what you posted earlier, so there is still some that I don't understand. But if you can let me know 1) what tools I need, and 2) the rough procedure to build, I will test it here and try to refine it.
>
> >> >>>>
> >> >>>> I can also look into any multicast issues on Android, and if multicast is really not possible on Android, then conditionally leave it out of testlo. Depending on how multicast behaves if you try to use it on Android (can it crash the app?), we may need to update the source.
>
> >> >>>>
> >> >>>> What is the best way to exchange the build code?
> >> >>>>
> >> >>>> mark
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Fernando Carello [mailto:fca...@gm...]
> >> >>>> Sent: Friday, April 10, 2020 1:35 PM
> >> >>>> To: liblo development list
> >> >>>> Subject: Re: [liblo] Android Anyone?
> >> >>>>
> >> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if testlo failed:
> >> >>>>
> >> >>>> --
> >> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
> >> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/, with debug_info, not stripped
>
> >> >>>> --
> >> >>>>
> >> >>>> I *think* that "testlo" wants to test the multicast interface, even if "configure" stated there isn't one on Android.
>
> >> >>>> So one could either fix testlo (preferred), or for the moment disable the multicast interface test and call it a day.
>
> >> >>>>
> >> >>>> Mark, let me know if I can be of further help.
> >> >>>> I could:
> >> >>>> - provide the Android liblo.so library I just built (32 bit only at the moment)
> >> >>>> - provide (rough) directions to install and configure the needed cross-compilation tools
> >> >>>>
> >> >>>> Fernando
> >> >>>>
> >> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss <Ma...@re...> ha scritto:
> >> >>>>>
> >> >>>>> Hi Fernando and Stephen,
> >> >>>>>
> >> >>>>> Much thanks for the quick replies, and also for the speedy investigation into my problem. I will study those logs and links, and will have some questions, I'm sure.
>
> >> >>>>>
> >> >>>>> When it comes Android, I am as new as it gets. I've only installed the SDK and NDK last weekend, and didn't even consider using Android two weeks ago. I have a steep learning curve, but that has never stopped me before.
>
> >> >>>>>
> >> >>>>> Thanks again for the help.
> >> >>>>>
> >> >>>>> mark
> >> >>>>>
> >> >>>>>
> >> >>>>> -----Original Message-----
> >> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
> >> >>>>> Sent: Friday, April 10, 2020 8:13 AM
> >> >>>>> To: liblo development list
> >> >>>>> Subject: Re: [liblo] Android Anyone?
> >> >>>>>
> >> >>>>>
> >> >>>>> Hi Mark,
> >> >>>>>
> >> >>>>> Fernando is on the right track.  Unfortunately I can't install Android
> >> >>>>> NDK and make it work for you at the moment, but in principle it
> >> >>>>> should.  I'd welcome any contribution to update the Android build
> >> >>>>> procedure.
> >> >>>>>
> >> >>>>> I am not sure why --host is failing for you Fernando.  I just tried
> >> >>>>> building with the only cross-compiler I have installed on my system,
> >> >>>>> MingW, and it configured and built just fine without trying to execute
> >> >>>>> the compiler output. Normally it should not do that as long as --host
> >> >>>>> and --build are not the same:
> >> >>>>>
> >> >>>>> https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html
> >> >>>>>
> >> >>>>> It looks like Travis has some Android NDK things available, so perhaps
> >> >>>>> I can get some CI configuration working to test an Android build:
> >> >>>>>
> >> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
> >> >>>>>
> >> >>>>> Steve
> >> >>>>>
> >> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello <fca...@gm...> wrote:
> >> >>>>> >
> >> >>>>> > Hi Mark,
> >> >>>>> > just my 2 cents (newbie here).
> >> >>>>> >
> >> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for other reasons (building OpenSSL).
> >> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9; I can build for 32-bit and 64-bit Android ARM targets.
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > Problem is, liblo's "configure" does not seem to like my environment; it pretends to run a cross-compiled executable, and obviously fails.
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > Specifically:
> >> >>>>> >
> >> >>>>> > ----
> >> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
> >> >>>>> > checking whether build environment is sane... yes
> >> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
> >> >>>>> > checking for gawk... gawk
> >> >>>>> > checking whether make sets $(MAKE)... yes
> >> >>>>> > checking whether make supports nested variables... yes
> >> >>>>> > checking whether to enable maintainer-specific portions of Makefiles... no
> >> >>>>> > checking whether make supports nested variables... (cached) yes
> >> >>>>> > checking for gcc... /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64  --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >> >>>>>
> >> >>>>> > checking whether the C compiler works... yes
> >> >>>>> > checking for C compiler default output file name... a.out
> >> >>>>> > checking for suffix of executables...
> >> >>>>> > checking whether we are cross compiling... configure: error: in `/home/fernando/src/liblo-0.31':
> >> >>>>> > configure: error: cannot run C compiled programs.
> >> >>>>> > If you meant to cross compile, use `--host'.
> >> >>>>> > See `config.log' for more details
> >> >>>>> >
> >> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
> >> >>>>> >
> >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
> >> >>>>> > configure: error: missing argument to --host-alias
> >> >>>>> > ---
> >> >>>>> >
> >> >>>>> > For completeness, my $CC:
> >> >>>>> >
> >> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
> >> >>>>> > /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64 --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>
> >> >>>>>
> >> >>>>> >
> >> >>>>> > My config.log is attached.
> >> >>>>> >
> >> >>>>> > Hope this helps.
> >> >>>>> > Please note, I'm no way an Android expert! :)
> >> >>>>> >
> >> >>>>> >
> >> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss <Ma...@re...> ha scritto:
> >> >>>>> >>
> >> >>>>> >> Hello Stephen, other developers, et.al.
> >> >>>>> >>
> >> >>>>> >> Thanks so much for keeping this project moving forward. I'm hoping to contribute, although in a small way.
> >> >>>>> >>
> >> >>>>> >> I first used liblo in 2015 for an augmented-reality project. That used it to communicate position data between Linux computers, and it worked very well.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> Now I'm using it in a rather large project, where multiple user-interface controllers are communicating with the main communications processor in a robotic system. I'm using multiple ports (five, at the moment), with each device containing multiple servers and also sending to multiple servers. It is working well when all of the devices are Linux.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> But we need tablets for the UI devices, and the Linux tablet that we tried fell on its face (BQ Aquaris M10), and we can find no others. So we have resigned ourselves to having to use Android tablets. So the task now entails porting the application and libraries to the Android SDK and NDK.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> It appears that the Android build procedure included in the liblo project hasn't worked since gcc was removed from the NDK some years back (the SDK now uses clang). Searching the web, nobody ever asks about liblo on Android. The last mention of Android on this mail list is six years ago. So I have a few questions:
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> 1) Has anybody ever used liblo on Android?
> >> >>>>> >> 2) Are there any known reasons why it might not work?
> >> >>>>> >> 3) If not, does anyone have any idea how to build liblo with the current Android NDK?
> >> >>>>> >>
> >> >>>>> >> I am new to Android development, although I've been doing embedded development for decades. Unless someone knows of a reason why it won't work, I'm willing to build liblo for Android and create a new Android build script (new, until an NDK update breaks it again). A minor contribution, maybe, but a key step for our project.
>
> >> >>>>>
> >> >>>>> >>
> >> >>>>> >> Last question: what do you think?
> >> >>>>> >>
> >> >>>>> >> Thanks,
> >> >>>>> >> Mark
> >> >>>>> >>
> >> >>>>> >> -------------------
> >> >>>>> >> Mark Hotchkiss
> >> >>>>> >> Louma Inc.
> >> >>>>> >> 4351 Clark Avenue
> >> >>>>> >> Long Beach, CA 90808
> >> >>>>> >> phone: (562) 230-1080
> >> >>>>> >> email:  ma...@re...
> >> >>>>> >>
> >> >>>>> >>
> >> >>>>> >> _______________________________________________
> >> >>>>> >> liblo-devel mailing list
> >> >>>>> >> lib...@li...
> >> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>> >
> >> >>>>> > _______________________________________________
> >> >>>>> > liblo-devel mailing list
> >> >>>>> > lib...@li...
> >> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>>
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> liblo-devel mailing list
> >> >>>>> lib...@li...
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>>
> >> >>>>> _______________________________________________
> >> >>>>> liblo-devel mailing list
> >> >>>>> lib...@li...
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> liblo-devel mailing list
> >> >>>> lib...@li...
> >> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >>
> >> >> _______________________________________________
> >> >> liblo-devel mailing list
> >> >> lib...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >> >
> >> > _______________________________________________
> >> > liblo-devel mailing list
> >> > lib...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >>
> >>
> >> _______________________________________________
> >> liblo-devel mailing list
> >> lib...@li...
> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> >
> > _______________________________________________
> > liblo-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] Android Anyone?

[Mark H. <Ma...@re...>]

Hi Stephen,

Success. But not without some confusion (I'm easily confused). Here is how
it went. Sorry if it's rather long.

When I first ran the script, it did not detect my installed NDK and
downloaded another copy. It surprised me, but after looking at why (that it
expects for it to be in the liblo project directory), I decided that that
was the best way to do it. My reasoning was 1) it will always use the
version of the NDK that the build script expects, 2) other possibly
incompatible configurations of the NDK that might exist on the system won't
cause the build to fail, and 3) the build script will not be outdated by
future releases of the NDK, as long as r21 remains available. And it doesn't
take long to load, and only need to load the first time. Based on all that,
I now think that Gradle is unnecessary.

Having said that, the build failed anyway.

The error I had was that the "index" function was missing. Having seen your
commit for that issue, I assumed that I was trying to build the wrong
version. After a few tries with other versions, I could not get rid of the
error, so I simply replaced the server.c file with your new one. Then that
error was gone and I got the other error, the multicast_iface change. But by
then I knew what to do.

So everything built fine and I now have a liblo.so file. I will link it in
with an application tomorrow, and then try to plug it into the Qt framework.
I will let you know how it goes.

Mucho thanks,
mark



-----Original Message-----
From: Stephen Sinclair [mailto:rad...@gm...]
Sent: Thursday, April 16, 2020 4:04 AM
To: liblo development list
Subject: Re: [liblo] Android Anyone?


Ok I can look into gradle from the command line, I simply followed
instructions I found for using the NDK from the command line which
indicated ndk-build.  I was quite happy to find something that didn't
require also downloading Android Studio.  Anyways, I'll see if I can
find more up to date information, thanks.

Steve

On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen  and Fernando,
>
> This is great !
>
> I have not run it yet (I'm locked out of the lab for cleaning) but I
looked at the script and I like it. The fact that it uses the most recent
NDK and Clang satisfies my client's requirements (I think). If it used
Gradle instead of ndk-build, it would be perfect. The NDK is moving toward
Gradle, and some fear that ndk-build may soon be deprecated. I doubt it
though, and if it becomes an issue I can make those changes.
>
> Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is rather
narrow, but I see no reason that it wouldn't run on any distribution that
runs the NDK.
>
> Thanks so much for this. I will let you know the results in a few hours.
>
> mark
>
> -----Original Message-----
> From: Fernando Carello [mailto:fca...@gm...]
> Sent: Wednesday, April 15, 2020 3:59 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
> Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it download
the Android NDK):
>
> ~/src/liblo/libs/arm64-v8a$ file liblo.so
> liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV),
dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1,
stripped
>
> I can't test it within a real Android app, but it should work straight
away.
>
> Fernando
>
>
> Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair
<rad...@gm...> ha scritto:
>>
>> Hi Fernando and Mark,
>>
>> What do you think of this method?
>>
>> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
>> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
>>
>> Basically, it downloads NDK 21, then runs automake to generate
>> config.h and lo.h, and then builds liblo using ndk-build.
>>
>> If this works for you, I'll update the README.
>>
>> regards,
>> Steve
>>
>> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...>
wrote:
>> >
>> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
>> > The newer NDKs seem to miss some stuff: not only "true" GCC but some
includes too.
>> > Of course if you would succeed building with the newest NDK, that would
be absolutely great!!
>> > Best of luck. Very interested in your Android client app too!
>> > Fernando
>> >
>> >
>> >
>> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>
>> >> Thanks so much Fernando.
>> >>
>> >> Today is a "paperwork" day, so I might get to testing that late
tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so
I will need to load r14b first. But I suspect that version was the magic
that I was missing.
>> >>
>> >> Of course, my goal will be to build it with the latest SDK/NDK
version.
>> >>
>> >> mark
>> >>
>> >> -----Original Message-----
>> >> From: Fernando Carello [mailto:fca...@gm...]
>> >> Sent: Friday, April 10, 2020 2:35 PM
>> >> To: liblo development list
>> >> Subject: Re: [liblo] Android Anyone?
>> >>
>> >> Oh I need to clear that you have to build one version at a time.
>> >> So let's say you first build Android 32 bit library: "source
./android_configure_armeabiv7.sh", make clean, configure, make etc.
>> >> Copy the resulting 32 bit .so somewhere safe (or it will be
overwritten).
>> >> Then build the 64 bit version: "source ./android_configure_arm64.sh",
make clean and so on.
>> >>
>> >>
>> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello
<fca...@gm...> ha scritto:
>> >>>
>> >>> Excellent.
>> >>>
>> >>> I uploaded the (configured and built) source tree on Dropbox for the
moment (I'm sure github would be better but I don't have an account and am a
total newbie vs git), along with the cross-compile configuring script I use.
>> >>>
>> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did not
try to build arm64 version of liblo):
>> >>>
https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_script
s.zip?dl=0
>> >>>
>> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of the
source tree (from liblo-0.31/src/.libs)
>> >>>
https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=
0
>> >>>
>> >>> Rough procedure:
>> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
>> >>>
https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?h
l=sr
>> >>>
>> >>> Unpack it somewhere; mine is simply in
>> >>>
>> >>> /home/fernando/android-ndk-r14b
>> >>> symlink:
>> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
>> >>>
>> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as
indicated in the script source.
>> >>> Run the script (as current user, no need to sudo) using source
(example: "source ./android_configure_armeabiv7.sh").
>> >>> The script will copy some files, create some links and set some
variables to enable cross-compiling for Android.
>> >>> Then move into liblo source, make clean, make distclean, run
"./configure --host=x86_64-pc-linux-gnu", run make.
>> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under
"src/.libs"
>> >>>
>> >>> That's all: let me know if I can be of further help.
>> >>>
>> >>> All the best,
>> >>> Fernando
>> >>>
>> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>
>> >>>> Fernando, that's not good news, it's GREAT news.
>> >>>>
>> >>>> I'm still perusing what you posted earlier, so there is still some
that I don't understand. But if you can let me know 1) what tools I need,
and 2) the rough procedure to build, I will test it here and try to refine
it.
>> >>>>
>> >>>> I can also look into any multicast issues on Android, and if
multicast is really not possible on Android, then conditionally leave it out
of testlo. Depending on how multicast behaves if you try to use it on
Android (can it crash the app?), we may need to update the source.
>> >>>>
>> >>>> What is the best way to exchange the build code?
>> >>>>
>> >>>> mark
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Fernando Carello [mailto:fca...@gm...]
>> >>>> Sent: Friday, April 10, 2020 1:35 PM
>> >>>> To: liblo development list
>> >>>> Subject: Re: [liblo] Android Anyone?
>> >>>>
>> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if
testlo failed:
>> >>>>
>> >>>> --
>> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
>> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1
(SYSV), dynamically linked, interpreter /system/, with debug_info, not
stripped
>> >>>> --
>> >>>>
>> >>>> I *think* that "testlo" wants to test the multicast interface, even
if "configure" stated there isn't one on Android.
>> >>>> So one could either fix testlo (preferred), or for the moment
disable the multicast interface test and call it a day.
>> >>>>
>> >>>> Mark, let me know if I can be of further help.
>> >>>> I could:
>> >>>> - provide the Android liblo.so library I just built (32 bit only at
the moment)
>> >>>> - provide (rough) directions to install and configure the needed
cross-compilation tools
>> >>>>
>> >>>> Fernando
>> >>>>
>> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>>
>> >>>>> Hi Fernando and Stephen,
>> >>>>>
>> >>>>> Much thanks for the quick replies, and also for the speedy
investigation into my problem. I will study those logs and links, and will
have some questions, I'm sure.
>> >>>>>
>> >>>>> When it comes Android, I am as new as it gets. I've only installed
the SDK and NDK last weekend, and didn't even consider using Android two
weeks ago. I have a steep learning curve, but that has never stopped me
before.
>> >>>>>
>> >>>>> Thanks again for the help.
>> >>>>>
>> >>>>> mark
>> >>>>>
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
>> >>>>> Sent: Friday, April 10, 2020 8:13 AM
>> >>>>> To: liblo development list
>> >>>>> Subject: Re: [liblo] Android Anyone?
>> >>>>>
>> >>>>>
>> >>>>> Hi Mark,
>> >>>>>
>> >>>>> Fernando is on the right track.  Unfortunately I can't install
Android
>> >>>>> NDK and make it work for you at the moment, but in principle it
>> >>>>> should.  I'd welcome any contribution to update the Android build
>> >>>>> procedure.
>> >>>>>
>> >>>>> I am not sure why --host is failing for you Fernando.  I just tried
>> >>>>> building with the only cross-compiler I have installed on my
system,
>> >>>>> MingW, and it configured and built just fine without trying to
execute
>> >>>>> the compiler output. Normally it should not do that as long as
--host
>> >>>>> and --build are not the same:
>> >>>>>
>> >>>>>
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation
.html
>> >>>>>
>> >>>>> It looks like Travis has some Android NDK things available, so
perhaps
>> >>>>> I can get some CI configuration working to test an Android build:
>> >>>>>
>> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
>> >>>>>
>> >>>>> Steve
>> >>>>>
>> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello
<fca...@gm...> wrote:
>> >>>>> >
>> >>>>> > Hi Mark,
>> >>>>> > just my 2 cents (newbie here).
>> >>>>> >
>> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for
other reasons (building OpenSSL).
>> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9; I
can build for 32-bit and 64-bit Android ARM targets.
>> >>>>>
>> >>>>> >
>> >>>>> > Problem is, liblo's "configure" does not seem to like my
environment; it pretends to run a cross-compiled executable, and obviously
fails.
>> >>>>>
>> >>>>> >
>> >>>>> > Specifically:
>> >>>>> >
>> >>>>> > ----
>> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
>> >>>>> > checking whether build environment is sane... yes
>> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
>> >>>>> > checking for gawk... gawk
>> >>>>> > checking whether make sets $(MAKE)... yes
>> >>>>> > checking whether make supports nested variables... yes
>> >>>>> > checking whether to enable maintainer-specific portions of
Makefiles... no
>> >>>>> > checking whether make supports nested variables... (cached) yes
>> >>>>> > checking for gcc...
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> > checking whether the C compiler works... yes
>> >>>>> > checking for C compiler default output file name... a.out
>> >>>>> > checking for suffix of executables...
>> >>>>> > checking whether we are cross compiling... configure: error: in
`/home/fernando/src/liblo-0.31':
>> >>>>> > configure: error: cannot run C compiled programs.
>> >>>>> > If you meant to cross compile, use `--host'.
>> >>>>> > See `config.log' for more details
>> >>>>> >
>> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
>> >>>>> > configure: error: missing argument to --host-alias
>> >>>>> > ---
>> >>>>> >
>> >>>>> > For completeness, my $CC:
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
>> >>>>> >
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> >
>> >>>>> > My config.log is attached.
>> >>>>> >
>> >>>>> > Hope this helps.
>> >>>>> > Please note, I'm no way an Android expert! :)
>> >>>>> >
>> >>>>> >
>> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>> >>
>> >>>>> >> Hello Stephen, other developers, et.al.
>> >>>>> >>
>> >>>>> >> Thanks so much for keeping this project moving forward. I'm
hoping to contribute, although in a small way.
>> >>>>> >>
>> >>>>> >> I first used liblo in 2015 for an augmented-reality project.
That used it to communicate position data between Linux computers, and it
worked very well.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Now I'm using it in a rather large project, where multiple
user-interface controllers are communicating with the main communications
processor in a robotic system. I'm using multiple ports (five, at the
moment), with each device containing multiple servers and also sending to
multiple servers. It is working well when all of the devices are Linux.
>> >>>>>
>> >>>>> >>
>> >>>>> >> But we need tablets for the UI devices, and the Linux tablet
that we tried fell on its face (BQ Aquaris M10), and we can find no others.
So we have resigned ourselves to having to use Android tablets. So the task
now entails porting the application and libraries to the Android SDK and
NDK.
>> >>>>>
>> >>>>> >>
>> >>>>> >> It appears that the Android build procedure included in the
liblo project hasn't worked since gcc was removed from the NDK some years
back (the SDK now uses clang). Searching the web, nobody ever asks about
liblo on Android. The last mention of Android on this mail list is six years
ago. So I have a few questions:
>> >>>>>
>> >>>>> >>
>> >>>>> >> 1) Has anybody ever used liblo on Android?
>> >>>>> >> 2) Are there any known reasons why it might not work?
>> >>>>> >> 3) If not, does anyone have any idea how to build liblo with the
current Android NDK?
>> >>>>> >>
>> >>>>> >> I am new to Android development, although I've been doing
embedded development for decades. Unless someone knows of a reason why it
won't work, I'm willing to build liblo for Android and create a new Android
build script (new, until an NDK update breaks it again). A minor
contribution, maybe, but a key step for our project.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Last question: what do you think?
>> >>>>> >>
>> >>>>> >> Thanks,
>> >>>>> >> Mark
>> >>>>> >>
>> >>>>> >> -------------------
>> >>>>> >> Mark Hotchkiss
>> >>>>> >> Louma Inc.
>> >>>>> >> 4351 Clark Avenue
>> >>>>> >> Long Beach, CA 90808
>> >>>>> >> phone: (562) 230-1080
>> >>>>> >> email:  ma...@re...
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> _______________________________________________
>> >>>>> >> liblo-devel mailing list
>> >>>>> >> lib...@li...
>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>> >
>> >>>>> > _______________________________________________
>> >>>>> > liblo-devel mailing list
>> >>>>> > lib...@li...
>> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>
>> >>>> _______________________________________________
>> >>>> liblo-devel mailing list
>> >>>> lib...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>
>> >> _______________________________________________
>> >> liblo-devel mailing list
>> >> lib...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] Android Anyone?

[Mark H. <Ma...@re...>]

Hi Stephen,

If it is more than a little effort, then don't bother. While ndk-build is
still supported, we need not worry, and it seems that other things break
with each release of the NDK (my experience from simply testing the NDK
example programs). So we may be revisiting this script in the future.
Building for the NDK seems to be a moving target.

Thanks again,
mark


-----Original Message-----
From: Stephen Sinclair [mailto:rad...@gm...]
Sent: Thursday, April 16, 2020 4:04 AM
To: liblo development list
Subject: Re: [liblo] Android Anyone?


Ok I can look into gradle from the command line, I simply followed
instructions I found for using the NDK from the command line which
indicated ndk-build.  I was quite happy to find something that didn't
require also downloading Android Studio.  Anyways, I'll see if I can
find more up to date information, thanks.

Steve

On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen  and Fernando,
>
> This is great !
>
> I have not run it yet (I'm locked out of the lab for cleaning) but I
looked at the script and I like it. The fact that it uses the most recent
NDK and Clang satisfies my client's requirements (I think). If it used
Gradle instead of ndk-build, it would be perfect. The NDK is moving toward
Gradle, and some fear that ndk-build may soon be deprecated. I doubt it
though, and if it becomes an issue I can make those changes.
>
> Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is rather
narrow, but I see no reason that it wouldn't run on any distribution that
runs the NDK.
>
> Thanks so much for this. I will let you know the results in a few hours.
>
> mark
>
> -----Original Message-----
> From: Fernando Carello [mailto:fca...@gm...]
> Sent: Wednesday, April 15, 2020 3:59 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
> Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it download
the Android NDK):
>
> ~/src/liblo/libs/arm64-v8a$ file liblo.so
> liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV),
dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1,
stripped
>
> I can't test it within a real Android app, but it should work straight
away.
>
> Fernando
>
>
> Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair
<rad...@gm...> ha scritto:
>>
>> Hi Fernando and Mark,
>>
>> What do you think of this method?
>>
>> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
>> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
>>
>> Basically, it downloads NDK 21, then runs automake to generate
>> config.h and lo.h, and then builds liblo using ndk-build.
>>
>> If this works for you, I'll update the README.
>>
>> regards,
>> Steve
>>
>> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...>
wrote:
>> >
>> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
>> > The newer NDKs seem to miss some stuff: not only "true" GCC but some
includes too.
>> > Of course if you would succeed building with the newest NDK, that would
be absolutely great!!
>> > Best of luck. Very interested in your Android client app too!
>> > Fernando
>> >
>> >
>> >
>> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>
>> >> Thanks so much Fernando.
>> >>
>> >> Today is a "paperwork" day, so I might get to testing that late
tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so
I will need to load r14b first. But I suspect that version was the magic
that I was missing.
>> >>
>> >> Of course, my goal will be to build it with the latest SDK/NDK
version.
>> >>
>> >> mark
>> >>
>> >> -----Original Message-----
>> >> From: Fernando Carello [mailto:fca...@gm...]
>> >> Sent: Friday, April 10, 2020 2:35 PM
>> >> To: liblo development list
>> >> Subject: Re: [liblo] Android Anyone?
>> >>
>> >> Oh I need to clear that you have to build one version at a time.
>> >> So let's say you first build Android 32 bit library: "source
./android_configure_armeabiv7.sh", make clean, configure, make etc.
>> >> Copy the resulting 32 bit .so somewhere safe (or it will be
overwritten).
>> >> Then build the 64 bit version: "source ./android_configure_arm64.sh",
make clean and so on.
>> >>
>> >>
>> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello
<fca...@gm...> ha scritto:
>> >>>
>> >>> Excellent.
>> >>>
>> >>> I uploaded the (configured and built) source tree on Dropbox for the
moment (I'm sure github would be better but I don't have an account and am a
total newbie vs git), along with the cross-compile configuring script I use.
>> >>>
>> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did not
try to build arm64 version of liblo):
>> >>>
https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_script
s.zip?dl=0
>> >>>
>> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of the
source tree (from liblo-0.31/src/.libs)
>> >>>
https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=
0
>> >>>
>> >>> Rough procedure:
>> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
>> >>>
https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?h
l=sr
>> >>>
>> >>> Unpack it somewhere; mine is simply in
>> >>>
>> >>> /home/fernando/android-ndk-r14b
>> >>> symlink:
>> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
>> >>>
>> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as
indicated in the script source.
>> >>> Run the script (as current user, no need to sudo) using source
(example: "source ./android_configure_armeabiv7.sh").
>> >>> The script will copy some files, create some links and set some
variables to enable cross-compiling for Android.
>> >>> Then move into liblo source, make clean, make distclean, run
"./configure --host=x86_64-pc-linux-gnu", run make.
>> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under
"src/.libs"
>> >>>
>> >>> That's all: let me know if I can be of further help.
>> >>>
>> >>> All the best,
>> >>> Fernando
>> >>>
>> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>
>> >>>> Fernando, that's not good news, it's GREAT news.
>> >>>>
>> >>>> I'm still perusing what you posted earlier, so there is still some
that I don't understand. But if you can let me know 1) what tools I need,
and 2) the rough procedure to build, I will test it here and try to refine
it.
>> >>>>
>> >>>> I can also look into any multicast issues on Android, and if
multicast is really not possible on Android, then conditionally leave it out
of testlo. Depending on how multicast behaves if you try to use it on
Android (can it crash the app?), we may need to update the source.
>> >>>>
>> >>>> What is the best way to exchange the build code?
>> >>>>
>> >>>> mark
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Fernando Carello [mailto:fca...@gm...]
>> >>>> Sent: Friday, April 10, 2020 1:35 PM
>> >>>> To: liblo development list
>> >>>> Subject: Re: [liblo] Android Anyone?
>> >>>>
>> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if
testlo failed:
>> >>>>
>> >>>> --
>> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
>> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1
(SYSV), dynamically linked, interpreter /system/, with debug_info, not
stripped
>> >>>> --
>> >>>>
>> >>>> I *think* that "testlo" wants to test the multicast interface, even
if "configure" stated there isn't one on Android.
>> >>>> So one could either fix testlo (preferred), or for the moment
disable the multicast interface test and call it a day.
>> >>>>
>> >>>> Mark, let me know if I can be of further help.
>> >>>> I could:
>> >>>> - provide the Android liblo.so library I just built (32 bit only at
the moment)
>> >>>> - provide (rough) directions to install and configure the needed
cross-compilation tools
>> >>>>
>> >>>> Fernando
>> >>>>
>> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>>
>> >>>>> Hi Fernando and Stephen,
>> >>>>>
>> >>>>> Much thanks for the quick replies, and also for the speedy
investigation into my problem. I will study those logs and links, and will
have some questions, I'm sure.
>> >>>>>
>> >>>>> When it comes Android, I am as new as it gets. I've only installed
the SDK and NDK last weekend, and didn't even consider using Android two
weeks ago. I have a steep learning curve, but that has never stopped me
before.
>> >>>>>
>> >>>>> Thanks again for the help.
>> >>>>>
>> >>>>> mark
>> >>>>>
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
>> >>>>> Sent: Friday, April 10, 2020 8:13 AM
>> >>>>> To: liblo development list
>> >>>>> Subject: Re: [liblo] Android Anyone?
>> >>>>>
>> >>>>>
>> >>>>> Hi Mark,
>> >>>>>
>> >>>>> Fernando is on the right track.  Unfortunately I can't install
Android
>> >>>>> NDK and make it work for you at the moment, but in principle it
>> >>>>> should.  I'd welcome any contribution to update the Android build
>> >>>>> procedure.
>> >>>>>
>> >>>>> I am not sure why --host is failing for you Fernando.  I just tried
>> >>>>> building with the only cross-compiler I have installed on my
system,
>> >>>>> MingW, and it configured and built just fine without trying to
execute
>> >>>>> the compiler output. Normally it should not do that as long as
--host
>> >>>>> and --build are not the same:
>> >>>>>
>> >>>>>
https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation
.html
>> >>>>>
>> >>>>> It looks like Travis has some Android NDK things available, so
perhaps
>> >>>>> I can get some CI configuration working to test an Android build:
>> >>>>>
>> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
>> >>>>>
>> >>>>> Steve
>> >>>>>
>> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello
<fca...@gm...> wrote:
>> >>>>> >
>> >>>>> > Hi Mark,
>> >>>>> > just my 2 cents (newbie here).
>> >>>>> >
>> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for
other reasons (building OpenSSL).
>> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9; I
can build for 32-bit and 64-bit Android ARM targets.
>> >>>>>
>> >>>>> >
>> >>>>> > Problem is, liblo's "configure" does not seem to like my
environment; it pretends to run a cross-compiled executable, and obviously
fails.
>> >>>>>
>> >>>>> >
>> >>>>> > Specifically:
>> >>>>> >
>> >>>>> > ----
>> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
>> >>>>> > checking whether build environment is sane... yes
>> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
>> >>>>> > checking for gawk... gawk
>> >>>>> > checking whether make sets $(MAKE)... yes
>> >>>>> > checking whether make supports nested variables... yes
>> >>>>> > checking whether to enable maintainer-specific portions of
Makefiles... no
>> >>>>> > checking whether make supports nested variables... (cached) yes
>> >>>>> > checking for gcc...
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> > checking whether the C compiler works... yes
>> >>>>> > checking for C compiler default output file name... a.out
>> >>>>> > checking for suffix of executables...
>> >>>>> > checking whether we are cross compiling... configure: error: in
`/home/fernando/src/liblo-0.31':
>> >>>>> > configure: error: cannot run C compiled programs.
>> >>>>> > If you meant to cross compile, use `--host'.
>> >>>>> > See `config.log' for more details
>> >>>>> >
>> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
>> >>>>> > configure: error: missing argument to --host-alias
>> >>>>> > ---
>> >>>>> >
>> >>>>> > For completeness, my $CC:
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
>> >>>>> >
/home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androide
abi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16
-ffunction-sections -fno-strict-aliasing -finline-limit=64
--sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> >
>> >>>>> > My config.log is attached.
>> >>>>> >
>> >>>>> > Hope this helps.
>> >>>>> > Please note, I'm no way an Android expert! :)
>> >>>>> >
>> >>>>> >
>> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss
<Ma...@re...> ha scritto:
>> >>>>> >>
>> >>>>> >> Hello Stephen, other developers, et.al.
>> >>>>> >>
>> >>>>> >> Thanks so much for keeping this project moving forward. I'm
hoping to contribute, although in a small way.
>> >>>>> >>
>> >>>>> >> I first used liblo in 2015 for an augmented-reality project.
That used it to communicate position data between Linux computers, and it
worked very well.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Now I'm using it in a rather large project, where multiple
user-interface controllers are communicating with the main communications
processor in a robotic system. I'm using multiple ports (five, at the
moment), with each device containing multiple servers and also sending to
multiple servers. It is working well when all of the devices are Linux.
>> >>>>>
>> >>>>> >>
>> >>>>> >> But we need tablets for the UI devices, and the Linux tablet
that we tried fell on its face (BQ Aquaris M10), and we can find no others.
So we have resigned ourselves to having to use Android tablets. So the task
now entails porting the application and libraries to the Android SDK and
NDK.
>> >>>>>
>> >>>>> >>
>> >>>>> >> It appears that the Android build procedure included in the
liblo project hasn't worked since gcc was removed from the NDK some years
back (the SDK now uses clang). Searching the web, nobody ever asks about
liblo on Android. The last mention of Android on this mail list is six years
ago. So I have a few questions:
>> >>>>>
>> >>>>> >>
>> >>>>> >> 1) Has anybody ever used liblo on Android?
>> >>>>> >> 2) Are there any known reasons why it might not work?
>> >>>>> >> 3) If not, does anyone have any idea how to build liblo with the
current Android NDK?
>> >>>>> >>
>> >>>>> >> I am new to Android development, although I've been doing
embedded development for decades. Unless someone knows of a reason why it
won't work, I'm willing to build liblo for Android and create a new Android
build script (new, until an NDK update breaks it again). A minor
contribution, maybe, but a key step for our project.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Last question: what do you think?
>> >>>>> >>
>> >>>>> >> Thanks,
>> >>>>> >> Mark
>> >>>>> >>
>> >>>>> >> -------------------
>> >>>>> >> Mark Hotchkiss
>> >>>>> >> Louma Inc.
>> >>>>> >> 4351 Clark Avenue
>> >>>>> >> Long Beach, CA 90808
>> >>>>> >> phone: (562) 230-1080
>> >>>>> >> email:  ma...@re...
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> _______________________________________________
>> >>>>> >> liblo-devel mailing list
>> >>>>> >> lib...@li...
>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>> >
>> >>>>> > _______________________________________________
>> >>>>> > liblo-devel mailing list
>> >>>>> > lib...@li...
>> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>
>> >>>> _______________________________________________
>> >>>> liblo-devel mailing list
>> >>>> lib...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>
>> >> _______________________________________________
>> >> liblo-devel mailing list
>> >> lib...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel


_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Re: [liblo] Android Anyone?

[Stephen S. <rad...@gm...>]

Ok I can look into gradle from the command line, I simply followed
instructions I found for using the NDK from the command line which
indicated ndk-build.  I was quite happy to find something that didn't
require also downloading Android Studio.  Anyways, I'll see if I can
find more up to date information, thanks.

Steve

On Thu, Apr 16, 2020 at 1:01 PM Mark Hotchkiss <Ma...@re...> wrote:
>
> Hi Stephen  and Fernando,
>
> This is great !
>
> I have not run it yet (I'm locked out of the lab for cleaning) but I looked at the script and I like it. The fact that it uses the most recent NDK and Clang satisfies my client's requirements (I think). If it used Gradle instead of ndk-build, it would be perfect. The NDK is moving toward Gradle, and some fear that ndk-build may soon be deprecated. I doubt it though, and if it becomes an issue I can make those changes.
>
> Like Fernando, I'm running on Ubuntu 18.04 amd64, so our testing is rather narrow, but I see no reason that it wouldn't run on any distribution that runs the NDK.
>
> Thanks so much for this. I will let you know the results in a few hours.
>
> mark
>
> -----Original Message-----
> From: Fernando Carello [mailto:fca...@gm...]
> Sent: Wednesday, April 15, 2020 3:59 AM
> To: liblo development list
> Subject: Re: [liblo] Android Anyone?
>
> Just tested on Ubuntu 18.04 amd64; it works (I purposedly let it download the Android NDK):
>
> ~/src/liblo/libs/arm64-v8a$ file liblo.so
> liblo.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e852fde4894cfd791b992aa97e714275c3f5ade1, stripped
>
> I can't test it within a real Android app, but it should work straight away.
>
> Fernando
>
>
> Il giorno mer 15 apr 2020 alle ore 12:35 Stephen Sinclair <rad...@gm...> ha scritto:
>>
>> Hi Fernando and Mark,
>>
>> What do you think of this method?
>>
>> https://github.com/radarsat1/liblo/blob/master/build/android_build.sh
>> https://travis-ci.org/github/radarsat1/liblo/jobs/675237189
>>
>> Basically, it downloads NDK 21, then runs automake to generate
>> config.h and lo.h, and then builds liblo using ndk-build.
>>
>> If this works for you, I'll update the README.
>>
>> regards,
>> Steve
>>
>> On Sat, Apr 11, 2020 at 12:13 AM Fernando Carello <fca...@gm...> wrote:
>> >
>> > Mark, indeed I had to install 14b to have success (with OpenSSL too).
>> > The newer NDKs seem to miss some stuff: not only "true" GCC but some includes too.
>> > Of course if you would succeed building with the newest NDK, that would be absolutely great!!
>> > Best of luck. Very interested in your Android client app too!
>> > Fernando
>> >
>> >
>> >
>> > Il giorno sab 11 apr 2020 alle ore 00:07 Mark Hotchkiss <Ma...@re...> ha scritto:
>> >>
>> >> Thanks so much Fernando.
>> >>
>> >> Today is a "paperwork" day, so I might get to testing that late tonight. If not, then tomorrow. I have the latest Android SDK/NDK loaded, so I will need to load r14b first. But I suspect that version was the magic that I was missing.
>> >>
>> >> Of course, my goal will be to build it with the latest SDK/NDK version.
>> >>
>> >> mark
>> >>
>> >> -----Original Message-----
>> >> From: Fernando Carello [mailto:fca...@gm...]
>> >> Sent: Friday, April 10, 2020 2:35 PM
>> >> To: liblo development list
>> >> Subject: Re: [liblo] Android Anyone?
>> >>
>> >> Oh I need to clear that you have to build one version at a time.
>> >> So let's say you first build Android 32 bit library: "source ./android_configure_armeabiv7.sh", make clean, configure, make etc.
>> >> Copy the resulting 32 bit .so somewhere safe (or it will be overwritten).
>> >> Then build the 64 bit version: "source ./android_configure_arm64.sh", make clean and so on.
>> >>
>> >>
>> >> Il giorno ven 10 apr 2020 alle ore 23:31 Fernando Carello <fca...@gm...> ha scritto:
>> >>>
>> >>> Excellent.
>> >>>
>> >>> I uploaded the (configured and built) source tree on Dropbox for the moment (I'm sure github would be better but I don't have an account and am a total newbie vs git), along with the cross-compile configuring script I use.
>> >>>
>> >>> 1. Scripts (note: I only tested the 32 bit version vs. liblo. Did not try to build arm64 version of liblo):
>> >>> https://www.dropbox.com/s/n82v53jbad6cwyb/android_crosscomp_configure_scripts.zip?dl=0
>> >>>
>> >>> 2. Liblo source tree. I also copied liblo.so.7.4.1 in the root of the source tree (from liblo-0.31/src/.libs)
>> >>> https://www.dropbox.com/s/lmkp4jn97478pe4/liblo-0.31_Android_tree.tar.gz?dl=0
>> >>>
>> >>> Rough procedure:
>> >>> Basically, you just need NDK v14b on Linux (I run Ubuntu 18.04):
>> >>> https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip?hl=sr
>> >>>
>> >>> Unpack it somewhere; mine is simply in
>> >>>
>> >>> /home/fernando/android-ndk-r14b
>> >>> symlink:
>> >>> /home/fernando/android-ndk  ->  /home/fernando/android-ndk-r14b
>> >>>
>> >>> Now edit the scripts (see 1.) to suit your NDK relative path, as indicated in the script source.
>> >>> Run the script (as current user, no need to sudo) using source (example: "source ./android_configure_armeabiv7.sh").
>> >>> The script will copy some files, create some links and set some variables to enable cross-compiling for Android.
>> >>> Then move into liblo source, make clean, make distclean, run "./configure --host=x86_64-pc-linux-gnu", run make.
>> >>> "testlo" errors notwithstanding, you should find liblo.7.4.1 under "src/.libs"
>> >>>
>> >>> That's all: let me know if I can be of further help.
>> >>>
>> >>> All the best,
>> >>> Fernando
>> >>>
>> >>> Il giorno ven 10 apr 2020 alle ore 22:48 Mark Hotchkiss <Ma...@re...> ha scritto:
>> >>>>
>> >>>> Fernando, that's not good news, it's GREAT news.
>> >>>>
>> >>>> I'm still perusing what you posted earlier, so there is still some that I don't understand. But if you can let me know 1) what tools I need, and 2) the rough procedure to build, I will test it here and try to refine it.
>> >>>>
>> >>>> I can also look into any multicast issues on Android, and if multicast is really not possible on Android, then conditionally leave it out of testlo. Depending on how multicast behaves if you try to use it on Android (can it crash the app?), we may need to update the source.
>> >>>>
>> >>>> What is the best way to exchange the build code?
>> >>>>
>> >>>> mark
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Fernando Carello [mailto:fca...@gm...]
>> >>>> Sent: Friday, April 10, 2020 1:35 PM
>> >>>> To: liblo development list
>> >>>> Subject: Re: [liblo] Android Anyone?
>> >>>>
>> >>>> Good news: liblo.so.7.4.1 for Android was actually built, even if testlo failed:
>> >>>>
>> >>>> --
>> >>>> fernando@ubuntu:~/src/liblo-0.31/src/.libs$ file liblo.so.7.4.1
>> >>>> liblo.so.7.4.1: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/, with debug_info, not stripped
>> >>>> --
>> >>>>
>> >>>> I *think* that "testlo" wants to test the multicast interface, even if "configure" stated there isn't one on Android.
>> >>>> So one could either fix testlo (preferred), or for the moment disable the multicast interface test and call it a day.
>> >>>>
>> >>>> Mark, let me know if I can be of further help.
>> >>>> I could:
>> >>>> - provide the Android liblo.so library I just built (32 bit only at the moment)
>> >>>> - provide (rough) directions to install and configure the needed cross-compilation tools
>> >>>>
>> >>>> Fernando
>> >>>>
>> >>>> Il giorno ven 10 apr 2020 alle ore 22:09 Mark Hotchkiss <Ma...@re...> ha scritto:
>> >>>>>
>> >>>>> Hi Fernando and Stephen,
>> >>>>>
>> >>>>> Much thanks for the quick replies, and also for the speedy investigation into my problem. I will study those logs and links, and will have some questions, I'm sure.
>> >>>>>
>> >>>>> When it comes Android, I am as new as it gets. I've only installed the SDK and NDK last weekend, and didn't even consider using Android two weeks ago. I have a steep learning curve, but that has never stopped me before.
>> >>>>>
>> >>>>> Thanks again for the help.
>> >>>>>
>> >>>>> mark
>> >>>>>
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Stephen Sinclair [mailto:rad...@gm...]
>> >>>>> Sent: Friday, April 10, 2020 8:13 AM
>> >>>>> To: liblo development list
>> >>>>> Subject: Re: [liblo] Android Anyone?
>> >>>>>
>> >>>>>
>> >>>>> Hi Mark,
>> >>>>>
>> >>>>> Fernando is on the right track.  Unfortunately I can't install Android
>> >>>>> NDK and make it work for you at the moment, but in principle it
>> >>>>> should.  I'd welcome any contribution to update the Android build
>> >>>>> procedure.
>> >>>>>
>> >>>>> I am not sure why --host is failing for you Fernando.  I just tried
>> >>>>> building with the only cross-compiler I have installed on my system,
>> >>>>> MingW, and it configured and built just fine without trying to execute
>> >>>>> the compiler output. Normally it should not do that as long as --host
>> >>>>> and --build are not the same:
>> >>>>>
>> >>>>> https://www.gnu.org/software/automake/manual/html_node/Cross_002dCompilation.html
>> >>>>>
>> >>>>> It looks like Travis has some Android NDK things available, so perhaps
>> >>>>> I can get some CI configuration working to test an Android build:
>> >>>>>
>> >>>>> https://github.com/android/ndk-samples/blob/master/.travis.yml
>> >>>>>
>> >>>>> Steve
>> >>>>>
>> >>>>> On Fri, Apr 10, 2020 at 12:45 PM Fernando Carello <fca...@gm...> wrote:
>> >>>>> >
>> >>>>> > Hi Mark,
>> >>>>> > just my 2 cents (newbie here).
>> >>>>> >
>> >>>>> > I set up an Android cross-compile environment on my Ubuntu, for other reasons (building OpenSSL).
>> >>>>> > Using an old version of NDK (14b), I still have "true" GCC 4.9; I can build for 32-bit and 64-bit Android ARM targets.
>> >>>>>
>> >>>>> >
>> >>>>> > Problem is, liblo's "configure" does not seem to like my environment; it pretends to run a cross-compiled executable, and obviously fails.
>> >>>>>
>> >>>>> >
>> >>>>> > Specifically:
>> >>>>> >
>> >>>>> > ----
>> >>>>> > checking for a BSD-compatible install... /usr/bin/install -c
>> >>>>> > checking whether build environment is sane... yes
>> >>>>> > checking for a thread-safe mkdir -p... /bin/mkdir -p
>> >>>>> > checking for gawk... gawk
>> >>>>> > checking whether make sets $(MAKE)... yes
>> >>>>> > checking whether make supports nested variables... yes
>> >>>>> > checking whether to enable maintainer-specific portions of Makefiles... no
>> >>>>> > checking whether make supports nested variables... (cached) yes
>> >>>>> > checking for gcc... /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9  -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64  --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> > checking whether the C compiler works... yes
>> >>>>> > checking for C compiler default output file name... a.out
>> >>>>> > checking for suffix of executables...
>> >>>>> > checking whether we are cross compiling... configure: error: in `/home/fernando/src/liblo-0.31':
>> >>>>> > configure: error: cannot run C compiled programs.
>> >>>>> > If you meant to cross compile, use `--host'.
>> >>>>> > See `config.log' for more details
>> >>>>> >
>> >>>>> > [ SO I PASSED --host TO ./CONFIGURE, BUT:]
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ ./configure --host
>> >>>>> > configure: error: missing argument to --host-alias
>> >>>>> > ---
>> >>>>> >
>> >>>>> > For completeness, my $CC:
>> >>>>> >
>> >>>>> > fernando@ubuntu:~/src/liblo-0.31$ echo $CC
>> >>>>> > /home/fernando/src/../android/android-toolchain-armv7/bin/arm-linux-androideabi-gcc-4.9 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -ffunction-sections -fno-strict-aliasing -finline-limit=64 --sysroot=/home/fernando/src/../android/android-toolchain-armv7/sysroot/
>> >>>>>
>> >>>>> >
>> >>>>> > My config.log is attached.
>> >>>>> >
>> >>>>> > Hope this helps.
>> >>>>> > Please note, I'm no way an Android expert! :)
>> >>>>> >
>> >>>>> >
>> >>>>> > Il giorno ven 10 apr 2020 alle ore 05:04 Mark Hotchkiss <Ma...@re...> ha scritto:
>> >>>>> >>
>> >>>>> >> Hello Stephen, other developers, et.al.
>> >>>>> >>
>> >>>>> >> Thanks so much for keeping this project moving forward. I'm hoping to contribute, although in a small way.
>> >>>>> >>
>> >>>>> >> I first used liblo in 2015 for an augmented-reality project. That used it to communicate position data between Linux computers, and it worked very well.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Now I'm using it in a rather large project, where multiple user-interface controllers are communicating with the main communications processor in a robotic system. I'm using multiple ports (five, at the moment), with each device containing multiple servers and also sending to multiple servers. It is working well when all of the devices are Linux.
>> >>>>>
>> >>>>> >>
>> >>>>> >> But we need tablets for the UI devices, and the Linux tablet that we tried fell on its face (BQ Aquaris M10), and we can find no others. So we have resigned ourselves to having to use Android tablets. So the task now entails porting the application and libraries to the Android SDK and NDK.
>> >>>>>
>> >>>>> >>
>> >>>>> >> It appears that the Android build procedure included in the liblo project hasn't worked since gcc was removed from the NDK some years back (the SDK now uses clang). Searching the web, nobody ever asks about liblo on Android. The last mention of Android on this mail list is six years ago. So I have a few questions:
>> >>>>>
>> >>>>> >>
>> >>>>> >> 1) Has anybody ever used liblo on Android?
>> >>>>> >> 2) Are there any known reasons why it might not work?
>> >>>>> >> 3) If not, does anyone have any idea how to build liblo with the current Android NDK?
>> >>>>> >>
>> >>>>> >> I am new to Android development, although I've been doing embedded development for decades. Unless someone knows of a reason why it won't work, I'm willing to build liblo for Android and create a new Android build script (new, until an NDK update breaks it again). A minor contribution, maybe, but a key step for our project.
>> >>>>>
>> >>>>> >>
>> >>>>> >> Last question: what do you think?
>> >>>>> >>
>> >>>>> >> Thanks,
>> >>>>> >> Mark
>> >>>>> >>
>> >>>>> >> -------------------
>> >>>>> >> Mark Hotchkiss
>> >>>>> >> Louma Inc.
>> >>>>> >> 4351 Clark Avenue
>> >>>>> >> Long Beach, CA 90808
>> >>>>> >> phone: (562) 230-1080
>> >>>>> >> email:  ma...@re...
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> _______________________________________________
>> >>>>> >> liblo-devel mailing list
>> >>>>> >> lib...@li...
>> >>>>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>> >
>> >>>>> > _______________________________________________
>> >>>>> > liblo-devel mailing list
>> >>>>> > lib...@li...
>> >>>>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> liblo-devel mailing list
>> >>>>> lib...@li...
>> >>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>>>
>> >>>> _______________________________________________
>> >>>> liblo-devel mailing list
>> >>>> lib...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >>
>> >> _______________________________________________
>> >> liblo-devel mailing list
>> >> lib...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> >
>> > _______________________________________________
>> > liblo-devel mailing list
>> > lib...@li...
>> > https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel