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