Alberto Luaces wrote:
El Lunes 18 Mayo 2009ES 17:53:13 Alberto Luaces escribió:
El Lunes 18 Mayo 2009ES 13:55:58 Loic Dachary escribió:
Based on your research it seems that we need to exclude armel from the
list of supported arch for OpenSceneGraph for the time being. Do you
see another solution ?
Yes, I'm following now Peter's suggestion, so I have now a "qemulated"
armel system on my computer, and now I'm building the package on this
platform. If I'm successful reproducing the error, I can ping the OSG list
for a fix or at least for a switch in the CMake system in order to
deactivate that feature, in the case it were the culprit. The downside is
that the compilation is very slow, but at least I don't have to wait
several weeks and in additon, I can make as many tests as I need.
I have located the problem. Unfortunately it lies on Sid g++ versions 4.3.3-10
and 4.4.0-5 of armel's g++.
* Antecedents:
Newer versions of OSG make use of GCC builtin atomic operations where
available in order to improve efficiency (__sync_bool_compare_and_swap,
__sync_sub_and_fetch, __sync_add_and_fetch...). The specific code that uses
those GCC intrinsic functions is located in OpenThreads, but inlined on the
headers this library.
* Problem:
On armel, if one links an object file using those intrinsic functions to make
a shared object with the g++ driver, the intrinsic functions remain undefined
on the resultant library, that's why the build of OSG package fails when
linking the first executable, osgviewer. I have written this small testcase:
debian-armel:~# cat foo.c
void doit(void **p, void *val, void *val2)
{
__sync_bool_compare_and_swap(p, val, val2);
}
debian-armel:~# gcc foo.c -c
debian-armel:~# g++ -shared foo.o -o libfoo.so
debian-armel:~# nm -D libfoo.so | grep sync
U __sync_bool_compare_and_swap_4
debian-armel:~# gcc -shared foo.o -o libfoo.so
debian-armel:~# nm -D libfoo.so | grep sync
debian-armel:~#
* Solutions:
I'm going to submit a bug report for g++, but anyway I don't think we are
going to get a fix anytime soon,
I don't know if it is allowed for the Debian packaging rules to change the
compiling options for certain platforms. If it were the case, I could dive
into OSG's CMake build system and put a switch in order to deactivate the use
of intrinsics. We would use that switch only for armel.
We could also modify OSG's test for the availability of intrinsics in order to
not only test if a program using them could be compiled, but also if the
compiler is also able to link a simple program with a library using them.
This way we could have a platform independent test, not just something
specific for armel.
Awesome work :-) If you come up with a way to disable this with a CMake
option, I'll set it for armel only in the upcoming 2.8.1 package. As
long as it does not change the functionalities (only speed), it is
acceptable.
Cheers
begin:vcard
fn:Loic Dachary
n:Dachary;Loic
org:pokersource
adr:;;12 bd Magenta;Paris;;75010;France
email;internet:l...@dachary.org
title:Senior Developer
tel;work:+33 9 51 18 43 38
tel;cell:+33 6 64 03 29 07
x-mozilla-html:FALSE
url:http://dachary.org/
version:2.1
end:vcard
