<div dir="ltr">Yes, because changing how typelib wraps its C++ objects on the Ruby side would break orocos.rb.<div><br></div><div>If it indeed solves your problem, I would make the method inline.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, May 20, 2014 at 9:41 PM, Alexander Duda <span dir="ltr"><<a href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div><div>Am 20.05.2014 um 15:55 schrieb Sylvain Joyeux <<a href="mailto:bir.sylvain@gmail.com" target="_blank">bir.sylvain@gmail.com</a>>:</div><div class=""><br><blockquote type="cite">
<div dir="ltr">No, I would go with linking the orocos.rb module against typelib_ruby, which is perfectly legal.</div></blockquote><br></div><div>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.</div>
<div><br></div><div><div>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. </div><div><div><br></div><div><div>
/* Returns the Value object wrapped into +value+ */</div><div>159 Value typelib_get(VALUE value)</div><div>160 {</div><div>161 void* object = 0;</div><div>162 Data_Get_Struct(value, void, object);</div><div>163 return *reinterpret_cast<Value*>(object);</div>
<div>164 }</div></div><div><br></div><div>Any objections if we copy the function to oroocs.rb and remove all includes to typelib_ruby?</div><div><br></div></div><div>Greets Alex</div><div><br></div></div><div class=""><div>
</div><blockquote type="cite"><div dir="ltr"><div><br></div><div>I do believe that there is already a pkg-config file that references typelib_ruby.</div></div></blockquote></div><blockquote type="cite">
<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, May 20, 2014 at 3:52 PM, Alexander Duda <span dir="ltr"><<a href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a>></span> wrote:<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<br><div><div>Am 20.05.2014 um 15:17 schrieb Sylvain Joyeux <<a href="mailto:bir.sylvain@gmail.com" target="_blank">bir.sylvain@gmail.com</a>>:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Tue, May 20, 2014 at 11:49 AM, Alexander Duda <span dir="ltr"><<a href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
is there a particular reason why toolchain-2.7 is not merged into<br>
master?</blockquote></div><div>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]</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am asking because the current master is still using dyncall<div><br>
0.6 which is not compatible with OS X 10.9.<br></div></blockquote><div>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) </div>
</div></div></div></blockquote><div><br></div><div>Ok, I wil have a look.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Furthermore there are a number of issues with the current build on OSX<br>
but I think they also apply for other Os:<br>
* rpath is not turned on for all targets therefore typelib_ruby cannot<br>
find some libs<br>
* rpath seperator is ";" instead of the used ":"<br>
* typelib_ruby is build as module. But at the same time its header are<br>
used by orocos.rb. This results in undefined references which works for<br>
gcc but not for clang. Therefore, either we should install a typlib_ruby<br>
lib or use header only.<br></blockquote></div><div>??? 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.</div>
</div></div></div></blockquote><div><br></div><div>According to <a href="http://stackoverflow.com/questions/7619607/how-portable-is-linking-executables-against-loadable-modules" target="_blank">http://stackoverflow.com/questions/7619607/how-portable-is-linking-executables-against-loadable-modules</a> this is not supported on OS X. In general the question is if this is good practice or not?</div>
<div><br></div><div>The error message is for tools/orocos.rb:</div><div><div>Undefined symbols for architecture x86_64:</div><div> "typelib_get(unsigned long)", referenced from:</div><div> local_output_port_write(unsigned long, unsigned long, unsigned long) in ruby_task_context.cc.o</div>
<div> local_input_port_read(unsigned long, unsigned long, unsigned long, unsigned long) in ruby_task_context.cc.o</div><div> property_do_read(unsigned long, unsigned long, unsigned long, unsigned long) in datahandling.cc.o</div>
<div> property_do_write(unsigned long, unsigned long, unsigned long, unsigned long) in datahandling.cc.o</div><div> attribute_do_read(unsigned long, unsigned long, unsigned long, unsigned long) in datahandling.cc.o</div>
<div> attribute_do_write(unsigned long, unsigned long, unsigned long, unsigned long) in datahandling.cc.o</div><div> operation_call(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long) in operations.cc.o</div>
<div><br></div><div>I am not sure if we should tune clang to not complain about undefined references. According to "<a href="http://www.akkadia.org/drepper/dsohowto.pdf%E2%80%9C" target="_blank">http://www.akkadia.org/drepper/dsohowto.pdf“</a> </div>
<div>this is should be avoided: "It is therefore highly recommended to never depend on undefined symbols.“</div><div><br></div><div>The options I see are:</div><div>* tune clang</div><div>* header only typelib_ruby interface </div>
<div>* installing typelib_ruby interface as system library </div><div><br></div><div>You would go for tune clang?</div><div><br></div><div>Greets Alex</div><div><br></div></div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div>
<div><br></div><div>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 ?</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I have a merged and fixed version on my machine. Shall I create a pull<br>
request?<br></blockquote><div>Yes, on github.</div><div><br></div><div>Sylvain</div></div></div></div>
</blockquote></div><div><br><div>
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>--</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Dipl.-Ing. Alexander Duda<br>Unterwasserrobotik<br>Robotics Innovation Center<br><br>Hauptgeschäftsstelle Standort Bremen:<br>DFKI GmbH<br>Robotics Innovation Center<br>Robert-Hooke-Straße 1<br>28359 Bremen, Germany<br><br>
Tel.: <a href="tel:%2B49%20421%20178%2045-6620" value="+49421178456620" target="_blank">+49 421 178 45-6620</a><br>Zentrale: <a href="tel:%2B49%20421%20178%2045-0" value="+49421178450" target="_blank">+49 421 178 45-0</a><br>
Fax: <a href="tel:%2B49%20421%20178%2045-4150" value="+49421178454150" target="_blank">+49 421 178 45-4150</a> (Faxe bitte namentlich kennzeichnen)<br>E-Mail: <a href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a><br>
<br>Weitere Informationen: <a href="http://www.dfki.de/robotik" target="_blank">http://www.dfki.de/robotik</a><br>-----------------------------------------------------------------------<br>Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern<br>Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster<br>(Vorsitzender) Dr. Walter Olthoff<br>Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>
Amtsgericht Kaiserslautern, HRB 2313<br>Sitz der Gesellschaft: Kaiserslautern (HRB 2313)<br>USt-Id.Nr.: DE 148646973<br>Steuernummer: 19/673/0060/3</div></div></div>
</div>
<br></div></div></blockquote></div></div></div><br></div>
</blockquote></div><div><div class="h5"><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br>--</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Dipl.-Ing. Alexander Duda<br>Unterwasserrobotik<br>Robotics Innovation Center<br><br>Hauptgeschäftsstelle Standort Bremen:<br>DFKI GmbH<br>Robotics Innovation Center<br>Robert-Hooke-Straße 1<br>28359 Bremen, Germany<br><br>
Tel.: <a href="tel:%2B49%20421%20178%2045-6620" value="+49421178456620" target="_blank">+49 421 178 45-6620</a><br>Zentrale: <a href="tel:%2B49%20421%20178%2045-0" value="+49421178450" target="_blank">+49 421 178 45-0</a><br>
Fax: <a href="tel:%2B49%20421%20178%2045-4150" value="+49421178454150" target="_blank">+49 421 178 45-4150</a> (Faxe bitte namentlich kennzeichnen)<br>E-Mail: <a href="mailto:Alexander.Duda@dfki.de" target="_blank">Alexander.Duda@dfki.de</a><br>
<br>Weitere Informationen: <a href="http://www.dfki.de/robotik" target="_blank">http://www.dfki.de/robotik</a><br>-----------------------------------------------------------------------<br>Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern<br>Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster<br>(Vorsitzender) Dr. Walter Olthoff<br>Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>
Amtsgericht Kaiserslautern, HRB 2313<br>Sitz der Gesellschaft: Kaiserslautern (HRB 2313)<br>USt-Id.Nr.: DE 148646973<br>Steuernummer: 19/673/0060/3</div></div></div>
</div>
<br></div></div></div></blockquote></div><br></div>