liblo-devel Mailing List for LibLO

Sounds great :)

For what it's worth, the "server threads" feature of liblo basically
just allows you to receive messages on a dedicated background thread.
Depending on your use case you could benefit from skipping wrapping
these and just use whatever Lua threading mechanism exists.  (I don't
know Lua, but I assume there is some threading support.)

Congrats on the callback support, that's the hard part with bindings.
Remember that if you are using server threads, the callback will be on
a different thread than the function that called
lo_server_thread_start(), so you may need a synchronization mechanism
if you call back into the Lua interpreter.  This may or may not defeat
the purpose of threading, depending on your scenario.

Steve


On Sun, Sep 24, 2017 at 9:28 PM, Thomas Brand <to...@tr...> wrote:
>
> Hello Steve,
>
> thanks for the insights, the $$ is interesting to know!
> I will happily share the binding file, it turns out to be more difficult
> than i thought..  This weekend server_thread_add_method() works for the
> first time with a lua callback method, this is pretty awesome IMHO.
> I'll be back :)
> Greetings
> Thomas
>
> On Sat, September 23, 2017 00:25, Stephen Sinclair wrote:
>> Hi Thomas,
>>
>>
>> If you get nice luajit bindings working perhaps we can even include
>> them with liblo.  Let me know how it goes.
>>
>> As for lo_send, indeed you should call lo_send_internal directly.
>> What the macro does is add these numbers called LO_MARKER_A and
>> LO_MARKER_B at the end of the variadic call, which are only there for
>> error checking.  This can be a hassle for bindings purposes, so if you add
>> $$ to the end of the typestring it won't check those numbers.
>>
>>
>> But it's probably easier to skip the varargs stuff entirely and just
>> use the lo_message_add_ interface, then call lo_send_message().  If you do
>> this just add your own variadic lo_send() that does the right thing for
>> Lua.
>>
>>
>> Steve
>>
>>
>>
>> On Sat, Sep 16, 2017 at 4:53 AM, Thomas Brand <to...@tr...> wrote:
>>
>>>
>>> Follow-up: pre-processing the header seems to work for lo_send with lua
>>> ffi:
>>> gcc -E  /usr/include/lo/lo.h|grep -v "^#" >lo_preprocessed.h I start to
>>> understand :)
>>>
>>> ---------------------------- Original Message
>>> ----------------------------
>>> Subject: Re: [liblo] Visibility of symbols in liblo.so
>>> From:    "Thomas Brand" <to...@tr...>
>>> Date:    Sat, September 16, 2017 09:54
>>> To:      "liblo development list" <lib...@li...>
>>> ------------------------------------------------------------------------
>>> --
>>>
>>>
>>> Hi,
>>> thanks Erik and Steve for your answers. I'm thinking about this for a few
>>> days, this question was pretty dumb (!). Nevertheless here is what
>>> brought me to it, i was playing with luajit [1], it allows to use shared
>>> objects (load('lo')) and then use them without complicated mappings. The
>>> mapping is sort of replicating the header file BUT it doesn't support
>>> macros. This lua code:
>>> --snip
>>> local ffi = require("ffi") ffi.cdef[[ int printf(const char *fmt, ...); ]]
>>> ffi.C.printf("Hello %s!", "world") --snap
>>> I was thinking i could do the same with lo_send(xx ,...) but since
>>> lo_send isn't visible in the .so this woulnd't work :) The solution was
>>> to wrap the ... part in lua, and simply lo_add_xxx for the variadic
>>> args. Still i don't understand if a macro is "only" syntactic sugar for
>>> the compiler. Or if a macro can always also be expressed as a regular
>>> method, that in given case would make a difference. Greetings
>>> Thomas
>>>
>>>
>>> [1] http://luajit.org/ext_ffi.html
>>>
>>>
>>> On Sat, September 16, 2017 01:03, Stephen Sinclair wrote:
>>>
>>>> Hi, yes lo_send is a macro that expands to lo_send_internal.
>>>>
>>>>
>>>>
>>>> On Windows the compiler for MSVC at least in older versions did not
>>>> support the variadic macros needed for the LO_MARKER trick, so it was
>>>> made a real function in that case.  You can check lo_macro.h and the
>>>> "#if
>>>> defined(USE_ANSI_C)" clause for details.
>>>>
>>>> Is there a reason you need to detect the lo_send symbol?  If you
>>>> describe the problem perhaps we can help.
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
>>>> <eri...@do...> wrote:
>>>>
>>>>
>>>>> If it’s a macro, it needs to be expanded at compile time, which
>>>>> means that it won’t be available in a dynamic library.
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> i found out that the lo_send() method isn't visible in the
>>>>>> generated .so
>>>>>> file. I'm bulding "normal" like mkdir _build && cd _build && cmake
>>>>>> ../cmake && make && sudo make
>>>>>> install This gives liblo.so.7.3.0. nm liblo.so.7.3.0 | grep lo_send
>>>>>> shows some instances but not the pure lo_send. Looking at the code
>>>>>> lo_send is a macro and uses the "..." arguments list. Can that
>>>>>> make the difference? Could lo_send be available in the shared
>>>>>> object or not because of other reasons? I also saw that lo_send is
>>>>>> in src/liblo.def (@65). I'm not sure if i understand correctly
>>>>>> what's going on, any hints are welcome. Thanks + best regards
>>>>>> Thomas
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> -----------------------------------------------------------------------
>>> -------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> liblo-devel mailing list lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>>
>>>
>>>
>>> -----------------------------------------------------------------------
>>> -------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> liblo-devel mailing list lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>
>> -------------------------------------------------------------------------
>> -----
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> liblo-devel mailing list lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hello Steve,

thanks for the insights, the $$ is interesting to know!
I will happily share the binding file, it turns out to be more difficult
than i thought..  This weekend server_thread_add_method() works for the
first time with a lua callback method, this is pretty awesome IMHO.
I'll be back :)
Greetings
Thomas

On Sat, September 23, 2017 00:25, Stephen Sinclair wrote:
> Hi Thomas,
>
>
> If you get nice luajit bindings working perhaps we can even include
> them with liblo.  Let me know how it goes.
>
> As for lo_send, indeed you should call lo_send_internal directly.
> What the macro does is add these numbers called LO_MARKER_A and
> LO_MARKER_B at the end of the variadic call, which are only there for
> error checking.  This can be a hassle for bindings purposes, so if you add
> $$ to the end of the typestring it won't check those numbers.
>
>
> But it's probably easier to skip the varargs stuff entirely and just
> use the lo_message_add_ interface, then call lo_send_message().  If you do
> this just add your own variadic lo_send() that does the right thing for
> Lua.
>
>
> Steve
>
>
>
> On Sat, Sep 16, 2017 at 4:53 AM, Thomas Brand <to...@tr...> wrote:
>
>>
>> Follow-up: pre-processing the header seems to work for lo_send with lua
>> ffi:
>> gcc -E  /usr/include/lo/lo.h|grep -v "^#" >lo_preprocessed.h I start to
>> understand :)
>>
>> ---------------------------- Original Message
>> ----------------------------
>> Subject: Re: [liblo] Visibility of symbols in liblo.so
>> From:    "Thomas Brand" <to...@tr...>
>> Date:    Sat, September 16, 2017 09:54
>> To:      "liblo development list" <lib...@li...>
>> ------------------------------------------------------------------------
>> --
>>
>>
>> Hi,
>> thanks Erik and Steve for your answers. I'm thinking about this for a few
>> days, this question was pretty dumb (!). Nevertheless here is what
>> brought me to it, i was playing with luajit [1], it allows to use shared
>> objects (load('lo')) and then use them without complicated mappings. The
>> mapping is sort of replicating the header file BUT it doesn't support
>> macros. This lua code:
>> --snip
>> local ffi = require("ffi") ffi.cdef[[ int printf(const char *fmt, ...); ]]
>> ffi.C.printf("Hello %s!", "world") --snap
>> I was thinking i could do the same with lo_send(xx ,...) but since
>> lo_send isn't visible in the .so this woulnd't work :) The solution was
>> to wrap the ... part in lua, and simply lo_add_xxx for the variadic
>> args. Still i don't understand if a macro is "only" syntactic sugar for
>> the compiler. Or if a macro can always also be expressed as a regular
>> method, that in given case would make a difference. Greetings
>> Thomas
>>
>>
>> [1] http://luajit.org/ext_ffi.html
>>
>>
>> On Sat, September 16, 2017 01:03, Stephen Sinclair wrote:
>>
>>> Hi, yes lo_send is a macro that expands to lo_send_internal.
>>>
>>>
>>>
>>> On Windows the compiler for MSVC at least in older versions did not
>>> support the variadic macros needed for the LO_MARKER trick, so it was
>>> made a real function in that case.  You can check lo_macro.h and the
>>> "#if
>>> defined(USE_ANSI_C)" clause for details.
>>>
>>> Is there a reason you need to detect the lo_send symbol?  If you
>>> describe the problem perhaps we can help.
>>>
>>> Steve
>>>
>>>
>>>
>>>
>>> On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
>>> <eri...@do...> wrote:
>>>
>>>
>>>> If it’s a macro, it needs to be expanded at compile time, which
>>>> means that it won’t be available in a dynamic library.
>>>>
>>>> Erik
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>> i found out that the lo_send() method isn't visible in the
>>>>> generated .so
>>>>> file. I'm bulding "normal" like mkdir _build && cd _build && cmake
>>>>> ../cmake && make && sudo make
>>>>> install This gives liblo.so.7.3.0. nm liblo.so.7.3.0 | grep lo_send
>>>>> shows some instances but not the pure lo_send. Looking at the code
>>>>> lo_send is a macro and uses the "..." arguments list. Can that
>>>>> make the difference? Could lo_send be available in the shared
>>>>> object or not because of other reasons? I also saw that lo_send is
>>>>> in src/liblo.def (@65). I'm not sure if i understand correctly
>>>>> what's going on, any hints are welcome. Thanks + best regards
>>>>> Thomas
>>>>>
>>>>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> -------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> liblo-devel mailing list lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> -------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> liblo-devel mailing list lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
> -------------------------------------------------------------------------
> -----
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hi Thomas,

If you get nice luajit bindings working perhaps we can even include
them with liblo.  Let me know how it goes.

As for lo_send, indeed you should call lo_send_internal directly.
What the macro does is add these numbers called LO_MARKER_A and
LO_MARKER_B at the end of the variadic call, which are only there for
error checking.  This can be a hassle for bindings purposes, so if you
add $$ to the end of the typestring it won't check those numbers.

But it's probably easier to skip the varargs stuff entirely and just
use the lo_message_add_ interface, then call lo_send_message().  If
you do this just add your own variadic lo_send() that does the right
thing for Lua.

Steve


On Sat, Sep 16, 2017 at 4:53 AM, Thomas Brand <to...@tr...> wrote:
>
> Follow-up: pre-processing the header seems to work for lo_send with lua ffi:
> gcc -E  /usr/include/lo/lo.h|grep -v "^#" >lo_preprocessed.h
> I start to understand :)
>
> ---------------------------- Original Message ----------------------------
> Subject: Re: [liblo] Visibility of symbols in liblo.so
> From:    "Thomas Brand" <to...@tr...>
> Date:    Sat, September 16, 2017 09:54
> To:      "liblo development list" <lib...@li...>
> --------------------------------------------------------------------------
>
> Hi,
> thanks Erik and Steve for your answers.
> I'm thinking about this for a few days, this question was pretty dumb (!).
> Nevertheless here is what brought me to it, i was playing with luajit [1],
> it allows to use shared objects (load('lo')) and then use them without
> complicated mappings. The mapping is sort of replicating the header file
> BUT it doesn't support macros.
> This lua code:
> --snip
> local ffi = require("ffi")
> ffi.cdef[[
> int printf(const char *fmt, ...);
> ]]
> ffi.C.printf("Hello %s!", "world")
> --snap
> I was thinking i could do the same with lo_send(xx ,...) but since lo_send
> isn't visible in the .so this woulnd't work :)
> The solution was to wrap the ... part in lua, and simply lo_add_xxx for
> the variadic args.
> Still i don't understand if a macro is "only" syntactic sugar for the
> compiler. Or if a macro can always also be expressed as a regular method,
> that in given case would make a difference.
> Greetings
> Thomas
>
> [1] http://luajit.org/ext_ffi.html
>
> On Sat, September 16, 2017 01:03, Stephen Sinclair wrote:
>> Hi, yes lo_send is a macro that expands to lo_send_internal.
>>
>>
>> On Windows the compiler for MSVC at least in older versions did not
>> support the variadic macros needed for the LO_MARKER trick, so it was made
>> a real function in that case.  You can check lo_macro.h and the "#if
>> defined(USE_ANSI_C)" clause for details.
>>
>> Is there a reason you need to detect the lo_send symbol?  If you
>> describe the problem perhaps we can help.
>>
>> Steve
>>
>>
>>
>> On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
>> <eri...@do...> wrote:
>>
>>> If it’s a macro, it needs to be expanded at compile time, which means
>>> that it won’t be available in a dynamic library.
>>>
>>> Erik
>>>
>>>
>>>
>>>
>>>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>>>
>>>>
>>>> Hi,
>>>> i found out that the lo_send() method isn't visible in the generated
>>>> .so
>>>> file. I'm bulding "normal" like
>>>> mkdir _build && cd _build && cmake ../cmake && make && sudo make
>>>> install This gives liblo.so.7.3.0.
>>>> nm liblo.so.7.3.0 | grep lo_send shows some instances but not the pure
>>>> lo_send. Looking at the code lo_send is a macro and uses the "..."
>>>> arguments list. Can that make the difference? Could lo_send be
>>>> available in the shared object or not because of other reasons? I also
>>>> saw that lo_send is in src/liblo.def (@65). I'm not sure if i
>>>> understand correctly what's going on, any hints are welcome. Thanks +
>>>> best regards Thomas
>>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Follow-up: pre-processing the header seems to work for lo_send with lua ffi:
gcc -E  /usr/include/lo/lo.h|grep -v "^#" >lo_preprocessed.h
I start to understand :)

---------------------------- Original Message ----------------------------
Subject: Re: [liblo] Visibility of symbols in liblo.so
From:    "Thomas Brand" <to...@tr...>
Date:    Sat, September 16, 2017 09:54
To:      "liblo development list" <lib...@li...>
--------------------------------------------------------------------------

Hi,
thanks Erik and Steve for your answers.
I'm thinking about this for a few days, this question was pretty dumb (!).
Nevertheless here is what brought me to it, i was playing with luajit [1],
it allows to use shared objects (load('lo')) and then use them without
complicated mappings. The mapping is sort of replicating the header file
BUT it doesn't support macros.
This lua code:
--snip
local ffi = require("ffi")
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")
--snap
I was thinking i could do the same with lo_send(xx ,...) but since lo_send
isn't visible in the .so this woulnd't work :)
The solution was to wrap the ... part in lua, and simply lo_add_xxx for
the variadic args.
Still i don't understand if a macro is "only" syntactic sugar for the
compiler. Or if a macro can always also be expressed as a regular method,
that in given case would make a difference.
Greetings
Thomas

[1] http://luajit.org/ext_ffi.html

On Sat, September 16, 2017 01:03, Stephen Sinclair wrote:
> Hi, yes lo_send is a macro that expands to lo_send_internal.
>
>
> On Windows the compiler for MSVC at least in older versions did not
> support the variadic macros needed for the LO_MARKER trick, so it was made
> a real function in that case.  You can check lo_macro.h and the "#if
> defined(USE_ANSI_C)" clause for details.
>
> Is there a reason you need to detect the lo_send symbol?  If you
> describe the problem perhaps we can help.
>
> Steve
>
>
>
> On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
> <eri...@do...> wrote:
>
>> If it’s a macro, it needs to be expanded at compile time, which means
>> that it won’t be available in a dynamic library.
>>
>> Erik
>>
>>
>>
>>
>>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>>
>>>
>>> Hi,
>>> i found out that the lo_send() method isn't visible in the generated
>>> .so
>>> file. I'm bulding "normal" like
>>> mkdir _build && cd _build && cmake ../cmake && make && sudo make
>>> install This gives liblo.so.7.3.0.
>>> nm liblo.so.7.3.0 | grep lo_send shows some instances but not the pure
>>> lo_send. Looking at the code lo_send is a macro and uses the "..."
>>> arguments list. Can that make the difference? Could lo_send be
>>> available in the shared object or not because of other reasons? I also
>>> saw that lo_send is in src/liblo.def (@65). I'm not sure if i
>>> understand correctly what's going on, any hints are welcome. Thanks +
>>> best regards Thomas
>>>



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
liblo-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,
thanks Erik and Steve for your answers.
I'm thinking about this for a few days, this question was pretty dumb (!).
Nevertheless here is what brought me to it, i was playing with luajit [1],
it allows to use shared objects (load('lo')) and then use them without
complicated mappings. The mapping is sort of replicating the header file
BUT it doesn't support macros.
This lua code:
--snip
local ffi = require("ffi")
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")
--snap
I was thinking i could do the same with lo_send(xx ,...) but since lo_send
isn't visible in the .so this woulnd't work :)
The solution was to wrap the ... part in lua, and simply lo_add_xxx for
the variadic args.
Still i don't understand if a macro is "only" syntactic sugar for the
compiler. Or if a macro can always also be expressed as a regular method,
that in given case would make a difference.
Greetings
Thomas

[1] http://luajit.org/ext_ffi.html

On Sat, September 16, 2017 01:03, Stephen Sinclair wrote:
> Hi, yes lo_send is a macro that expands to lo_send_internal.
>
>
> On Windows the compiler for MSVC at least in older versions did not
> support the variadic macros needed for the LO_MARKER trick, so it was made
> a real function in that case.  You can check lo_macro.h and the "#if
> defined(USE_ANSI_C)" clause for details.
>
> Is there a reason you need to detect the lo_send symbol?  If you
> describe the problem perhaps we can help.
>
> Steve
>
>
>
> On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
> <eri...@do...> wrote:
>
>> If it’s a macro, it needs to be expanded at compile time, which means
>> that it won’t be available in a dynamic library.
>>
>> Erik
>>
>>
>>
>>
>>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>>
>>>
>>> Hi,
>>> i found out that the lo_send() method isn't visible in the generated
>>> .so
>>> file. I'm bulding "normal" like
>>> mkdir _build && cd _build && cmake ../cmake && make && sudo make
>>> install This gives liblo.so.7.3.0.
>>> nm liblo.so.7.3.0 | grep lo_send shows some instances but not the pure
>>> lo_send. Looking at the code lo_send is a macro and uses the "..."
>>> arguments list. Can that make the difference? Could lo_send be
>>> available in the shared object or not because of other reasons? I also
>>> saw that lo_send is in src/liblo.def (@65). I'm not sure if i
>>> understand correctly what's going on, any hints are welcome. Thanks +
>>> best regards Thomas
>>>

Hi, yes lo_send is a macro that expands to lo_send_internal.

On Windows the compiler for MSVC at least in older versions did not
support the variadic macros needed for the LO_MARKER trick, so it was
made a real function in that case.  You can check lo_macro.h and the
"#if defined(USE_ANSI_C)" clause for details.

Is there a reason you need to detect the lo_send symbol?  If you
describe the problem perhaps we can help.

Steve


On Fri, Sep 15, 2017 at 10:56 AM, Erik Ronström
<eri...@do...> wrote:
> If it’s a macro, it needs to be expanded at compile time, which means that it won’t be available in a dynamic library.
>
> Erik
>
>
>
>> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
>>
>> Hi,
>> i found out that the lo_send() method isn't visible in the generated .so
>> file.
>> I'm bulding "normal" like
>> mkdir _build && cd _build && cmake ../cmake && make && sudo make install
>> This gives liblo.so.7.3.0.
>> nm liblo.so.7.3.0 | grep lo_send
>> shows some instances but not the pure lo_send.
>> Looking at the code lo_send is a macro and uses the "..." arguments list.
>> Can that make the difference? Could lo_send be available in the shared
>> object or not because of other reasons? I also saw that lo_send is in
>> src/liblo.def (@65). I'm not sure if i understand correctly what's going
>> on, any hints are welcome.
>> Thanks + best regards
>> Thomas
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

If it’s a macro, it needs to be expanded at compile time, which means that it won’t be available in a dynamic library.

Erik



> 7 sep. 2017 kl. 20:34 skrev Thomas Brand <to...@tr...>:
> 
> Hi,
> i found out that the lo_send() method isn't visible in the generated .so
> file.
> I'm bulding "normal" like
> mkdir _build && cd _build && cmake ../cmake && make && sudo make install
> This gives liblo.so.7.3.0.
> nm liblo.so.7.3.0 | grep lo_send
> shows some instances but not the pure lo_send.
> Looking at the code lo_send is a macro and uses the "..." arguments list.
> Can that make the difference? Could lo_send be available in the shared
> object or not because of other reasons? I also saw that lo_send is in
> src/liblo.def (@65). I'm not sure if i understand correctly what's going
> on, any hints are welcome.
> Thanks + best regards
> Thomas
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,
i found out that the lo_send() method isn't visible in the generated .so
file.
I'm bulding "normal" like
mkdir _build && cd _build && cmake ../cmake && make && sudo make install
This gives liblo.so.7.3.0.
nm liblo.so.7.3.0 | grep lo_send
shows some instances but not the pure lo_send.
Looking at the code lo_send is a macro and uses the "..." arguments list.
Can that make the difference? Could lo_send be available in the shared
object or not because of other reasons? I also saw that lo_send is in
src/liblo.def (@65). I'm not sure if i understand correctly what's going
on, any hints are welcome.
Thanks + best regards
Thomas