utilrb builds into source dir?

It looks like utilrb builds into the source directory and when combined with the need to build the orocos_toolchain from source as sudo, causes build errors on an sshfs-mounted filesystem. Separately, this also prevents sharing the code directory between multiple machines with different O/S's.

What is utilrb building into the source dir? Is this actually necessary? How hard would it be to change it to build into the build dir?

Note that this builds fine on the same machine if I use local source dir's.

Cheers
S

==> Processing plain cmake package: 'utilrb'
==> Building with env: '/opt/ros/hydro/env.sh'
Makefile exists, skipping explicit cmake invocation...
==> make cmake_check_build_system in '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
==> make -j8 -l8 in '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
INFO: cannot load the Hoe gem. Distribution is disabled
INFO: error message is: cannot load such file -- hoe
creating Makefile
make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
linking shared-object utilrb_ext.so
/usr/bin/ld: i386 architecture of input file `proc.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `swap.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `utilrb_ext.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `value_set.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `weakref.o' is incompatible with i386:x86-64 output
utilrb_ext.o: In function `__gnu_cxx::new_allocator<std::_Rb_tree_node /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
value_set.o: In function `value_set_alloc':
/home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/value_set.cc:22: undefined reference to `operator new(unsigned int)'
weakref.o: In function `weakref_alloc':
/home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/weakref.cc:45: undefined reference to `operator new(unsigned int)'
weakref.o: In function `std::_Rb_tree<unsigned long, unsigned long, std::_Identity /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
weakref.o: In function `__gnu_cxx::new_allocator<std::_Rb_tree_node /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
weakref.o:/usr/include/c++/4.7/ext/new_allocator.h:94: more undefined references to `operator new(unsigned int)' follow
/usr/bin/ld: proc.o: file class ELFCLASS32 incompatible with ELFCLASS64
/usr/bin/ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
make[3]: *** [utilrb_ext.so] Error 1
rake aborted!
cannot build the C extension

Tasks: TOP => default => setup
(See full trace by running task with --trace)
make[2]: *** [CMakeFiles/utilrb_ext] Error 1
make[1]: *** [CMakeFiles/utilrb_ext.dir/all] Error 2
make: *** [all] Error 2

utilrb builds into source dir?

>
>
> So are you saying that utilrb/master builds into an architecture-specific
> dir inside the source dir? If so then I think that resolves sharing the
> source dir between multiple architectures at the same time. But it still
> presents issues when building over a network mounted filesystem, due to the
> sudo/root-mapping problem. You frequently need to make the source dir
> world-read/write to allow a root-user-mapped-to-nobody access. I think that
> the need for sudo builds is actually driven by something outside of utilrb
> .... (Peter? Ruben?) ...
>
> Is it really standard practice to build into the source dir for gem
> packages?! Wow ...
>
Do you really have to build using sudo ?! Wow .... :P

After a quick look at rake-compiler, it would be possible to build anywhere
(we would have to expose that functionality as an argument to the rake task
though) as well as install the resulting shared object anywhere as well. It
would need some careful planning, though, to find where exactly we want it
to go :P

Sylvain

utilrb builds into source dir?

utilrb is following standard practices for ruby packages (actually gem
packages), which is to build extensions in the gem directory. However,
utilrb master deals with the multiarch problem (thanks to the rake-compiler
plugin) by building into a directory that is named after the build
architecture (e.g. tmp/x86-64_linux_gnu or something like that).

Sylvain

2014-02-25 12:35 GMT+01:00 S Roderick <kiwi [dot] net [..] ...>:

> It looks like utilrb builds into the source directory and when combined
> with the need to build the orocos_toolchain from source as sudo, causes
> build errors on an sshfs-mounted filesystem. Separately, this also prevents
> sharing the code directory between multiple machines with different O/S's.
>
> What is utilrb building into the source dir? Is this actually necessary?
> How hard would it be to change it to build into the build dir?
>
> Note that this builds fine on the same machine if I use local source dir's.
>
> Cheers
> S
>
> ==> Processing plain cmake package: 'utilrb'
> ==> Building with env: '/opt/ros/hydro/env.sh'
> Makefile exists, skipping explicit cmake invocation...
> ==> make cmake_check_build_system in
> '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
> ==> make -j8 -l8 in
> '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
> INFO: cannot load the Hoe gem. Distribution is disabled
> INFO: error message is: cannot load such file -- hoe
> creating Makefile
> make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent
> make rule.
> linking shared-object utilrb_ext.so
> /usr/bin/ld: i386 architecture of input file `proc.o' is incompatible with
> i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `swap.o' is incompatible with
> i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `utilrb_ext.o' is
> incompatible with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `value_set.o' is incompatible
> with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `weakref.o' is incompatible
> with i386:x86-64 output
> utilrb_ext.o: In function
> `__gnu_cxx::new_allocator<std::_Rb_tree_node > >::allocate(unsigned int, void const*)':
> /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to
> `operator new(unsigned int)'
> value_set.o: In function `value_set_alloc':
> /home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/value_set.cc:22:
> undefined reference to `operator new(unsigned int)'
> weakref.o: In function `weakref_alloc':
> /home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/weakref.cc:45:
> undefined reference to `operator new(unsigned int)'
> weakref.o: In function `std::_Rb_tree<unsigned long, unsigned long,
> std::_Identity<unsigned long>, std::less<unsigned long>,
> std::allocator<unsigned long> >::_M_get_node()':
> /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to
> `operator new(unsigned int)'
> weakref.o: In function
> `__gnu_cxx::new_allocator<std::_Rb_tree_node > >::allocate(unsigned int, void const*)':
> /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to
> `operator new(unsigned int)'
> weakref.o:/usr/include/c++/4.7/ext/new_allocator.h:94: more undefined
> references to `operator new(unsigned int)' follow
> /usr/bin/ld: proc.o: file class ELFCLASS32 incompatible with ELFCLASS64
> /usr/bin/ld: final link failed: File in wrong format
> collect2: error: ld returned 1 exit status
> make[3]: *** [utilrb_ext.so] Error 1
> rake aborted!
> cannot build the C extension
>
> Tasks: TOP => default => setup
> (See full trace by running task with --trace)
> make[2]: *** [CMakeFiles/utilrb_ext] Error 1
> make[1]: *** [CMakeFiles/utilrb_ext.dir/all] Error 2
> make: *** [all] Error 2
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>

utilrb builds into source dir?

On May 16, 2014, at 10:12 , Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:

> utilrb is following standard practices for ruby packages (actually gem packages), which is to build extensions in the gem directory. However, utilrb master deals with the multiarch problem (thanks to the rake-compiler plugin) by building into a directory that is named after the build architecture (e.g. tmp/x86-64_linux_gnu or something like that).
>
> Sylvain

So are you saying that utilrb/master builds into an architecture-specific dir inside the source dir? If so then I think that resolves sharing the source dir between multiple architectures at the same time. But it still presents issues when building over a network mounted filesystem, due to the sudo/root-mapping problem. You frequently need to make the source dir world-read/write to allow a root-user-mapped-to-nobody access. I think that the need for sudo builds is actually driven by something outside of utilrb .... (Peter? Ruben?) ...

Is it really standard practice to build into the source dir for gem packages?! Wow ...
S

>
>
> 2014-02-25 12:35 GMT+01:00 S Roderick <kiwi [dot] net [..] ...>:
> It looks like utilrb builds into the source directory and when combined with the need to build the orocos_toolchain from source as sudo, causes build errors on an sshfs-mounted filesystem. Separately, this also prevents sharing the code directory between multiple machines with different O/S's.
>
> What is utilrb building into the source dir? Is this actually necessary? How hard would it be to change it to build into the build dir?
>
> Note that this builds fine on the same machine if I use local source dir's.
>
> Cheers
> S
>
> ==> Processing plain cmake package: 'utilrb'
> ==> Building with env: '/opt/ros/hydro/env.sh'
> Makefile exists, skipping explicit cmake invocation...
> ==> make cmake_check_build_system in '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
> ==> make -j8 -l8 in '/home/sroderick/orocos_ws/build_isolated/utilrb/install'
> INFO: cannot load the Hoe gem. Distribution is disabled
> INFO: error message is: cannot load such file -- hoe
> creating Makefile
> make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
> linking shared-object utilrb_ext.so
> /usr/bin/ld: i386 architecture of input file `proc.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `swap.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `utilrb_ext.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `value_set.o' is incompatible with i386:x86-64 output
> /usr/bin/ld: i386 architecture of input file `weakref.o' is incompatible with i386:x86-64 output
> utilrb_ext.o: In function `__gnu_cxx::new_allocator<std::_Rb_tree_node > /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
> value_set.o: In function `value_set_alloc':
> /home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/value_set.cc:22: undefined reference to `operator new(unsigned int)'
> weakref.o: In function `weakref_alloc':
> /home/sroderick/ssc/code/orocos_toolchain/utilrb/ext/weakref.cc:45: undefined reference to `operator new(unsigned int)'
> weakref.o: In function `std::_Rb_tree<unsigned long, unsigned long, std::_Identity > /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
> weakref.o: In function `__gnu_cxx::new_allocator<std::_Rb_tree_node > /usr/include/c++/4.7/ext/new_allocator.h:94: undefined reference to `operator new(unsigned int)'
> weakref.o:/usr/include/c++/4.7/ext/new_allocator.h:94: more undefined references to `operator new(unsigned int)' follow
> /usr/bin/ld: proc.o: file class ELFCLASS32 incompatible with ELFCLASS64
> /usr/bin/ld: final link failed: File in wrong format
> collect2: error: ld returned 1 exit status
> make[3]: *** [utilrb_ext.so] Error 1
> rake aborted!
> cannot build the C extension
>
> Tasks: TOP => default => setup
> (See full trace by running task with --trace)
> make[2]: *** [CMakeFiles/utilrb_ext] Error 1
> make[1]: *** [CMakeFiles/utilrb_ext.dir/all] Error 2
> make: *** [all] Error 2
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>