liblo-devel Mailing List for LibLO

On Sun, Apr 17, 2011 at 2:04 PM, nico <sl1...@gm...> wrote:
> hi,
> does anybody successfully produced a .dll of liblo with mingw?
> if so, how to do that?

Hi Nico,

What are the results of running autogen.sh?  You should have mingw's
version of autoconf and automake installed.  It should work, if all
goes well, though I haven't tested it in a while.

Steve

hi,
does anybody successfully produced a .dll of liblo with mingw?
if so, how to do that?

best regards,
nico

Hi Luis,

After talking with some friends, it seems like that would be the best way to
go. Back in the thread Stephen offered to put a note about that back on the
website.

Morgan

On Sun, Apr 17, 2011 at 3:46 AM, Luis Garrido <
lui...@us...> wrote:

> Is not a dual-licensing scheme a possible solution for this issue?
>
> Software makers not willing to deal with the GPL could license liblo
> from its authors under a commercial license, perhaps paying a
> reasonable fee significantly lower than the cost of developing a
> replacement.
>
> It is another way of supporting the goals of copyleft, since that
> commercial version doesn't have to be any different to the GPL one and
> liblo authors could invest that money into improving it.
>
> Just another take.
>
> Luis
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Is not a dual-licensing scheme a possible solution for this issue?

Software makers not willing to deal with the GPL could license liblo
from its authors under a commercial license, perhaps paying a
reasonable fee significantly lower than the cost of developing a
replacement.

It is another way of supporting the goals of copyleft, since that
commercial version doesn't have to be any different to the GPL one and
liblo authors could invest that money into improving it.

Just another take.

Luis

Hi Stephen,

[I'm coming into this a bit late, so for what it's worth...]

The GPL and LGPL only have social impact insofar as the best or most
appropriate software for a particular task is only available with a GPL or
LGPL license. This is explicitly acknowledged by the FSF, though I can't
provide a reference at the moment.

It seems to me a bit contradictory to encourage others to create libraries
that duplicate the functionality of your software while providing a more
permissive license (or in Andy's terms, less legal baggage). Once a drop-in
replacement for liblo with a more permissive license is available, there is
no longer much incentive to use liblo over the other library – the software
developer is free to make their software free no matter whether some of its
components are (L)GPL or something more permissive. The only incentive to
use the (L)GPL software, in that case, is that by being a user of liblo,
they may, by association, contribute to the betterment of the project so
that it may at some point become superior.

By this logic I would agree with Adrian's original point that liblo should
consider a more permissive license in order to both avoid duplication of
effort in other libraries and promote the usage of OSC – something I have an
investment in as somebody who occasionally has to read datasheets and
interface with digital equipment.

Morgan

On Fri, Feb 18, 2011 at 10:35 AM, Stephen Sinclair <rad...@gm...>wrote:

> Glad to be getting some more feedback on this topic, thanks..
>
> On Fri, Feb 18, 2011 at 9:00 AM, Sebastien Bourdeauducq
> <seb...@mi...> wrote:
> > On Fri, 2011-02-18 at 13:42 +0000, Nicholas J Humfrey wrote:
> >> Generally I don't mind if liblo is used in closed-source projects as
> >> long as any changes or improvements to liblo are contributed back to
> >> the project. Is there a suggested a license that achieves that?
> >
> > LGPL does.
> >
> > That being said, I wouldn't mind if liblo was GPL.
>
> It was previously.  That's the thing.. switching to LGPL actually was
> the _compromise_ for us, because we were receiving many requests to
> use liblo in commercial products.  I know that LGPL is not exactly
> encouraged by the FSF, but it was the closest thing I could find to a
> license that enforces GPL-style values (i.e. remains modifiable by the
> user, requires changes be contributed back) but allows usage in
> closed-source applications.
>
> I know that the liblo community considers software freedom important;
> in matters like these, it's good to remember that it is indeed more
> important than getting more users at any cost---besides, it's not like
> there aren't other options for sending and receiving OSC.  I'd rather
> not see modified versions of liblo out there where I don't know what
> changes have been made.
>
> If people have a harder time using other solutions, it's not really
> our problem.  The OSC spec is extremely well documented, so I don't
> see why anyone would depend so heavily on a single implementation.  If
> they like liblo enough, perhaps they should consider using the GPL for
> their product.  That's the whole idea of having a healthy free
> software ecosystem.
>
> Well, that's how I see it anyways.
>
> > I have personally
> > taken the GPL principles to the next level and I'm building a single
> > board computer for video synthesis that is totally open source down to
> > the processor hardware design. It runs liblo, with some modifications
> > (strip out the auto**** "portable build system" and abstract the socket
> > code that did not play well with the RTEMS network stack). See
> > www.milkymist.org
>
> That is awesome.  :)
>
> Steve
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi Stephen,

[I'm coming into this a bit late, so for what it's worth...]

The GPL and LGPL only have social impact insofar as the best or most
appropriate software for a particular task is only available with a GPL or
LGPL license. This is explicitly acknowledged by the FSF, though I can't
provide a reference at the moment.

It seems to me a bit contradictory to encourage others to create libraries
that duplicate the functionality of your software while providing a more
permissive license (or in Andy's terms, less legal baggage). Once a drop-in
replacement for liblo with a more permissive license is available, there is
no longer much incentive to use liblo over the other library – the software
developer is free to make their software free no matter whether some of its
components are (L)GPL or something more permissive. The only incentive to
use the (L)GPL software, in that case, is that by being a user of liblo,
they may, by association, contribute to the betterment of the project so
that it may at some point become superior.

By this logic I would agree with Adrian's original point that liblo should
consider a more permissive license in order to both avoid duplication of
effort in other libraries and promote the usage of OSC – something I have an
investment in as somebody who occasionally has to read datasheets and
interface with digital equipment.

Morgan

On Fri, Feb 18, 2011 at 10:35 AM, Stephen Sinclair <rad...@gm...>wrote:

> Glad to be getting some more feedback on this topic, thanks..
>
> On Fri, Feb 18, 2011 at 9:00 AM, Sebastien Bourdeauducq
> <seb...@mi...> wrote:
> > On Fri, 2011-02-18 at 13:42 +0000, Nicholas J Humfrey wrote:
> >> Generally I don't mind if liblo is used in closed-source projects as
> >> long as any changes or improvements to liblo are contributed back to
> >> the project. Is there a suggested a license that achieves that?
> >
> > LGPL does.
> >
> > That being said, I wouldn't mind if liblo was GPL.
>
> It was previously.  That's the thing.. switching to LGPL actually was
> the _compromise_ for us, because we were receiving many requests to
> use liblo in commercial products.  I know that LGPL is not exactly
> encouraged by the FSF, but it was the closest thing I could find to a
> license that enforces GPL-style values (i.e. remains modifiable by the
> user, requires changes be contributed back) but allows usage in
> closed-source applications.
>
> I know that the liblo community considers software freedom important;
> in matters like these, it's good to remember that it is indeed more
> important than getting more users at any cost---besides, it's not like
> there aren't other options for sending and receiving OSC.  I'd rather
> not see modified versions of liblo out there where I don't know what
> changes have been made.
>
> If people have a harder time using other solutions, it's not really
> our problem.  The OSC spec is extremely well documented, so I don't
> see why anyone would depend so heavily on a single implementation.  If
> they like liblo enough, perhaps they should consider using the GPL for
> their product.  That's the whole idea of having a healthy free
> software ecosystem.
>
> Well, that's how I see it anyways.
>
> > I have personally
> > taken the GPL principles to the next level and I'm building a single
> > board computer for video synthesis that is totally open source down to
> > the processor hardware design. It runs liblo, with some modifications
> > (strip out the auto**** "portable build system" and abstract the socket
> > code that did not play well with the RTEMS network stack). See
> > www.milkymist.org
>
> That is awesome.  :)
>
> Steve
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Fri, Apr 8, 2011 at 12:56 AM, Stephen Sinclair <rad...@gm...> wrote:
> Luis,
>
> Okay that explains it a little better.  So if I understand correctly,
> taking the case of a DSSI GUI for example, the problem is that the
> DSSI starts up a server which gets bound to an IPv6 local socket, and
> the host tries sending to "localhost" but this resolves to IPv4 so
> they don't find each other.

Nope. Please disregard my first post about the "localhost" stuff, I
was working under wrong assumptions.

The problematic issue is associating the machine name with the IPv6
loopback interface. liblo _server_ code seems to create IPv4 sockets
in both cases, but I'd hazard the guess that the _client_ code does
something different and tries to connect to use IPv6 in the second
case.

--------------------------------------------------------------
Case 1 (working):
--------------------------------------------------------------

$ cat /etc/hosts

127.0.0.1       localhost.localdomain   localhost       localhost4
::1             localhost6.localdomain6 localhost6

$ hexter

hexter: Warning: DSSI path not set
hexter: Defaulting to
"/usr/local/lib64/dssi:/usr/lib64/dssi:/usr/local/lib/dssi:/usr/lib/dssi:/home/user/.dssi"


hexter: OSC URL is:
osc.udp://advent.lan:13745/dssi/hexter/hexter/chan00

host: Ready
hexter_gtk starting (pid 3509)...

$ lsof -i | grep hexter
hexter    3503 user    5u  IPv4  79699      0t0  UDP *:13745
hexter_gt 3509 user    5u  IPv4  79699      0t0  UDP *:13745
hexter_gt 3509 user   12u  IPv4  79721      0t0  UDP *:15248


--------------------------------------------------------------
Case 2 (not working):
--------------------------------------------------------------

$ cat /etc/hosts
127.0.0.1	localhost.localdomain	localhost	localhost4
::1		advent localhost6.localdomain6	localhost6

$ hexter

hexter: Warning: DSSI path not set
hexter: Defaulting to
"/usr/local/lib64/dssi:/usr/lib64/dssi:/usr/local/lib/dssi:/usr/lib/dssi:/home/user/.dssi"


hexter: OSC URL is:
osc.udp://advent:13927/dssi/hexter/hexter/chan00

host: Ready
hexter_gtk starting (pid 3521)...

$ lsof -i | grep hexter
hexter    3515 user    5u  IPv4  82723      0t0  UDP *:13927
hexter_gt 3521 user    5u  IPv4  82723      0t0  UDP *:13927
hexter_gt 3521 user   11u  IPv4  82743      0t0  UDP *:13928

Luis,

Okay that explains it a little better.  So if I understand correctly,
taking the case of a DSSI GUI for example, the problem is that the
DSSI starts up a server which gets bound to an IPv6 local socket, and
the host tries sending to "localhost" but this resolves to IPv4 so
they don't find each other.

This sounds to me like the DSSI needs to be able to tell the host what
type of socket it opened, and then the host could send to localhost or
localhost6 accordingly.  LibLo does allow setting the address to
anything you want, so it's a matter of the DSSI host doing the right
thing.  One change I can imagine is that I guess there's no way
currently to ask LibLo what IP version it is serving, or in fact to
ask liblo to use one or the other when starting a server.  Perhaps
there needs to be a way.

One simple solution for local connections that I can imagine would be
to use UNIX sockets instead of IP sockets...

Steve

On Thu, Apr 7, 2011 at 6:27 PM, Luis Garrido
<lui...@us...> wrote:
> Hi, Stephen.
>
> Upon further investigation, the problem appears when NetworkManager
> modifies /etc/hosts so the machine name is both associated to an IP
> and an IPv6 address, like in the following example:
>
> $ cat /etc/hosts
> 192.168.0.128   advent
> 127.0.0.1       localhost.localdomain   localhost       localhost4
> ::1     advent  localhost6.localdomain6 localhost6
>
> In this situation both DSSI host and GUI can't communicate: the host
> launches the GUI process, but the startup protocol never progresses to
> the point the GUI is displayed on the screen. I don't know enough of
> the internals of name resolution as to hazard a guess about why a
> configuration like that is a problem.
>
> Apparently this causes problems with other software too, notably kerberos.
>
> As of 01/2011, NM developers seem to have given up on updating
> /etc/hosts automatically.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=648725
>
> Once the machine name is not associated to the IPv6 loopback address
> anymore the problem disappears.
>
> $ cat /etc/hosts
> 192.168.0.128   advent
> 127.0.0.1       localhost.localdomain   localhost       localhost4
> ::1     localhost6.localdomain6 localhost6
>
> I am not sure if there is something that can be done on liblo's side
> to make it more resilient to situations like this or not.
>
> Regards,
>
> Luis
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi, Stephen.

Upon further investigation, the problem appears when NetworkManager
modifies /etc/hosts so the machine name is both associated to an IP
and an IPv6 address, like in the following example:

$ cat /etc/hosts
192.168.0.128   advent
127.0.0.1       localhost.localdomain   localhost       localhost4
::1     advent  localhost6.localdomain6 localhost6

In this situation both DSSI host and GUI can't communicate: the host
launches the GUI process, but the startup protocol never progresses to
the point the GUI is displayed on the screen. I don't know enough of
the internals of name resolution as to hazard a guess about why a
configuration like that is a problem.

Apparently this causes problems with other software too, notably kerberos.

As of 01/2011, NM developers seem to have given up on updating
/etc/hosts automatically.

https://bugzilla.redhat.com/show_bug.cgi?id=648725

Once the machine name is not associated to the IPv6 loopback address
anymore the problem disappears.

$ cat /etc/hosts
192.168.0.128   advent
127.0.0.1       localhost.localdomain   localhost       localhost4
::1     localhost6.localdomain6 localhost6

I am not sure if there is something that can be done on liblo's side
to make it more resilient to situations like this or not.

Regards,

Luis

Hi Luis,

I'm not entirely clear on the problem you're reporting.

I agree that there's perhaps a problem.. for both liblo addresses and
servers, if there is a problem resolving the local host name it uses
"localhost", where this is not valid for IPv6.  However, I'm not
completely clear on what the expected behaviour is.  Can you describe
what behaviour you expect to see?

Switching the defaults to "localhost6" would not solve the issue as
far as I can tell, since when compiled with --enable-ipv6, it's
supposed to support both IPv4 and IPv6, so how can we choose such a
default?

I admit that I've found the IPv6 stuff to be quite difficult to get my
head around, it's not unlikely that there are still some things
needing improvement in this area.

Steve

On Tue, Apr 5, 2011 at 3:45 AM, Luis Garrido
<lui...@us...> wrote:
> On Tue, Apr 5, 2011 at 2:34 AM, Luis Garrido
> <lui...@us...> wrote:
>
>> The crux of the problem seems to be that the name "localhost" is not
>> resolvable to an IPv6 address. Using liblo as a server generates an
>> address that uses "localhost" as the hostname. But when you use liblo
>
> Well, on second tests, no. Actually liblo generates a URL with the
> configured hostname:
>
> hexter: OSC URL is:
> osc.udp://advent:18285/dssi/hexter/hexter/chan00
>
> ping and ping6 both resolve that name.
>
> :scratches head:
>
> Luis
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Tue, Apr 5, 2011 at 2:34 AM, Luis Garrido
<lui...@us...> wrote:

> The crux of the problem seems to be that the name "localhost" is not
> resolvable to an IPv6 address. Using liblo as a server generates an
> address that uses "localhost" as the hostname. But when you use liblo

Well, on second tests, no. Actually liblo generates a URL with the
configured hostname:

hexter: OSC URL is:
osc.udp://advent:18285/dssi/hexter/hexter/chan00

ping and ping6 both resolve that name.

:scratches head:

Luis

Fedora Core users have traditionally this problem with DSSI GUIs,
probably because the liblo packager uses the --enable-ipv6 flag.

This is a quick rundown of how the default NetworkManager
configuration works in Fedora:

---------------------------------------------------------------------

$ cat /etc/hosts
192.168.0.128	advent	# Added by NetworkManager
127.0.0.1	localhost.localdomain	localhost	localhost4
::1	advent	localhost6.localdomain6	localhost6
$ ping -c1 localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.061 ms

--- localhost.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms
$ ping -c1 localhost6
PING advent (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.058 ms

--- advent ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms
$ ping6 -c1 localhost
unknown host
$ ping6 -c1 localhost6
PING localhost6(advent) 56 data bytes
64 bytes from advent: icmp_seq=1 ttl=64 time=0.066 ms

--- localhost6 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.066/0.066/0.066/0.000 ms

---------------------------------------------------------------------

The crux of the problem seems to be that the name "localhost" is not
resolvable to an IPv6 address. Using liblo as a server generates an
address that uses "localhost" as the hostname. But when you use liblo
as a client it tries to perform an IPv6 resolution first and it
consequently fails.

What would be a reasonable way of resolving/addressing :-) this situation?

Thanks,

Luis