2012/4/25 Nicolas Chauvet <kwizart@xxxxxxxxx>: > 2012/4/23 Dan Horák <dan@xxxxxxxx>: > .. >> I'm usually skipping such packages as there is a lot of other work on >> s390, but when I dealt with them I've used either the gcc or C++ >> primitives or the atomic_ops library. The Pixie package seems to be on >> my list of blocked by atomic ops, there should be more, but I haven't >> analysed all failures yet. Hi Dan, Been the Pixie maintainer and trying to fix the issue. I can test anything on either my AC100 running F14 or 'soonish' a Pandaboard with f17 armv7hl. As Dan told me, there is a need to use a generic gcc intrinsinc code for atomic_ops from this files: http://pixie.svn.sourceforge.net/viewvc/pixie/trunk/src/ri/atomic.h?revision=1226&view=markup The current generic function doesn't work and I wasn't able to sort that out. (even if it look trivial, there is others problem than adding a missing headers as the error sugguest) http://arm.koji.fedoraproject.org/koji/getfile?taskID=753420&name=build.log I wonder if It wouldn't worth to grab some equivalent ARM asm to implement the same functions for __ARM_EABI__. For the record, Pixie is an image renderer engine and requires massive CPU load which worth to have optim enabled. This is also a 'Final component' so it will not be triggered by something that could run on a armv5 only CPU. So my question is how can I opt-out armv5tel to force armv7l compilation instead ? Thx for your help. Nicolas (kwizart) _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
