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.
Regards,
Alberto
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
