[Rock-dev] typelib: merging toolchain-2.7 into master / OS 10.9

Sylvain Joyeux bir.sylvain at gmail.com
Tue May 20 22:01:20 CEST 2014 

Yes, because changing how typelib wraps its C++ objects on the Ruby side
would break orocos.rb.

If it indeed solves your problem, I would make the method inline.


On Tue, May 20, 2014 at 9:41 PM, Alexander Duda <Alexander.Duda at dfki.de>wrote:

>
> Am 20.05.2014 um 15:55 schrieb Sylvain Joyeux <bir.sylvain at gmail.com>:
>
> No, I would go with linking the orocos.rb module against typelib_ruby,
> which is perfectly legal.
>
>
> This is only legal on unix based systems because they do not distinct
> between modules and shared libraries. OS X is using Mach-O as binary format
> and here it is not allowed to directly link against modules.
>
> In the case of orocos.rb the only function in question is typelib_get
> which can easily be implemented as inline function or we could simply copy
> it to orocos.rb.
>
>  /* Returns the Value object wrapped into +value+ */
> 159 Value typelib_get(VALUE value)
> 160 {
> 161     void* object = 0;
> 162     Data_Get_Struct(value, void, object);
> 163     return *reinterpret_cast<Value*>(object);
> 164 }
>
> Any objections if we copy the function to oroocs.rb and remove all
> includes to typelib_ruby?
>
> Greets Alex
>
>
>
>
> I do believe that there is already a pkg-config file that references
> typelib_ruby.
>
>
>
> On Tue, May 20, 2014 at 3:52 PM, Alexander Duda <Alexander.Duda at dfki.de>wrote:
>
>>
>> Am 20.05.2014 um 15:17 schrieb Sylvain Joyeux <bir.sylvain at gmail.com>:
>>
>>
>>
>>
>> On Tue, May 20, 2014 at 11:49 AM, Alexander Duda <Alexander.Duda at dfki.de>wrote:
>>
>>> Hi,
>>>
>>> is there a particular reason why toolchain-2.7 is not merged into
>>> master?
>>
>> Because the orocos toolchain developers develop on the side because
>> that's easier for them, and believe that it is my job to merge the stuff
>> back into master proper. We therefore end up with a fork of typelib, which
>> we wanted to avoid in the first place [/rant]
>>
>>
>>> I am asking because the current master is still using dyncall
>>>
>>> 0.6 which is not compatible with OS X 10.9.
>>>
>> dyncall is being unused for a pretty long time in typelib ... I think
>> that if it is indeed problematic, we should probably just rip out the
>> support for method calls from typelib altogether. (These days, ffi would be
>> a much better choice)
>>
>>
>> Ok, I wil have a look.
>>
>>
>>> Furthermore there are a number of issues with the current build on OSX
>>> but I think they also apply for other Os:
>>> * rpath is not turned on for all targets therefore typelib_ruby cannot
>>> find some libs
>>> * rpath seperator is ";" instead of the used ":"
>>> * typelib_ruby is build as module. But at the same time its header are
>>> used by orocos.rb. This results in undefined references which works for
>>> gcc but not for clang. Therefore, either we should install a typlib_ruby
>>> lib or use header only.
>>>
>> ??? Don't understand this. You are allowed to link to a module. Moreover,
>> the whole point of having dynamically loadable modules is that undefined
>> references should be allowed. We should definitely not install two versions
>> of the same shared object.
>>
>>
>> According to
>> http://stackoverflow.com/questions/7619607/how-portable-is-linking-executables-against-loadable-modulesthis is not supported on OS X. In general the question is if this is good
>> practice or not?
>>
>> The error message is for tools/orocos.rb:
>> Undefined symbols for architecture x86_64:
>>   "typelib_get(unsigned long)", referenced from:
>>       local_output_port_write(unsigned long, unsigned long, unsigned
>> long) in ruby_task_context.cc.o
>>       local_input_port_read(unsigned long, unsigned long, unsigned long,
>> unsigned long) in ruby_task_context.cc.o
>>       property_do_read(unsigned long, unsigned long, unsigned long,
>> unsigned long) in datahandling.cc.o
>>       property_do_write(unsigned long, unsigned long, unsigned long,
>> unsigned long) in datahandling.cc.o
>>       attribute_do_read(unsigned long, unsigned long, unsigned long,
>> unsigned long) in datahandling.cc.o
>>       attribute_do_write(unsigned long, unsigned long, unsigned long,
>> unsigned long) in datahandling.cc.o
>>       operation_call(unsigned long, unsigned long, unsigned long,
>> unsigned long, unsigned long, unsigned long) in operations.cc.o
>>
>> I am not sure if we should tune clang to not complain about undefined
>> references. According to "http://www.akkadia.org/drepper/dsohowto.pdf“
>> this is should be avoided: "It is therefore highly recommended to never
>> depend on undefined symbols.“
>>
>> The options I see are:
>> * tune clang
>> * header only typelib_ruby interface
>> * installing typelib_ruby interface as system library
>>
>> You would go for tune clang?
>>
>> Greets Alex
>>
>>
>>
>> In other words, I think there *is* a way to setup typelib_ruby so that
>> clang does not complain. What specific error do you get ?
>>
>>> I have a merged and fixed version on my machine. Shall I create a pull
>>> request?
>>>
>> Yes, on github.
>>
>> Sylvain
>>
>>
>>
>> --
>> Dipl.-Ing. Alexander Duda
>> Unterwasserrobotik
>> Robotics Innovation Center
>>
>> Hauptgeschäftsstelle Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 1
>> 28359 Bremen, Germany
>>
>> Tel.:     +49 421 178 45-6620
>> Zentrale: +49 421 178 45-0
>> Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>> E-Mail:   Alexander.Duda at dfki.de
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.:    DE 148646973
>> Steuernummer:  19/673/0060/3
>>
>>
>
>
> --
> Dipl.-Ing. Alexander Duda
> Unterwasserrobotik
> Robotics Innovation Center
>
> Hauptgeschäftsstelle Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 1
> 28359 Bremen, Germany
>
> Tel.:     +49 421 178 45-6620
> Zentrale: +49 421 178 45-0
> Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
> E-Mail:   Alexander.Duda at dfki.de
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.:    DE 148646973
> Steuernummer:  19/673/0060/3
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140520/7192d3b0/attachment.htm

More information about the Rock-dev mailing list