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

[Sylvain Joyeux]

No, I would go with linking the orocos.rb module against typelib_ruby,
which is perfectly legal.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140520/f8c5b896/attachment-0001.htm