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

Tue May 20 21:41:36 CEST 2014

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-modules this 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/5074baec/attachment-0001.htm 