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-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: [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
