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 <[email protected]>wrote: > > Am 20.05.2014 um 15:17 schrieb Sylvain Joyeux <[email protected]>: > > > > > On Tue, May 20, 2014 at 11:49 AM, Alexander Duda > <[email protected]>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: [email protected] > > 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 > >
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
