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 <[email protected]>wrote: > > Am 20.05.2014 um 15:55 schrieb Sylvain Joyeux <[email protected]>: > > 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 <[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 >> >> > > > -- > 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
