Summary: | media-libs/xine-lib: xineplug_decode_mpeg2.so: undefined symbol: constants (when compiled with USE="altivec") | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Steffen <verbuggt> |
Component: | New packages | Assignee: | PPC Porters <ppc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | flameeyes, pageexec |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | PPC | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Steffen
2006-05-29 04:19:27 UTC
from a quick look, the culprit is probably in src/libmpeg2/idct_altivec.c that has inline asm versions of some functions. i'm not sure what the point of this asm is as the comment on top says that it was basically generated by gcc itself... anyway, one explanation for the missing symbol could be that some optimization in gcc 3.4+ simply omits the 'constants' array from the object file as it is not actually used for any meaningful purpose, as far as the compiler is concerned (note that there's a feeble attempt at introducing a dummy 'use' by reading out the first member, but gcc is smarter than that ;-). proper solution would be to add 'constants' to the input constraints of the asm block, or better, not use this old gcc generated asm at all, i can hardly imagine that it's better than what a current compiler can generate. Thanks for reporting, I was able to get lu_zero rewriting the altivec code so that it works correctly, so it's fixed in -r11 now. Thanks Diego and lu_zero and the PaX Team, I just tried it and it works like a champ! No Textrels are left in -r11 and the Altivec code works great, the CPU usage dropped significantly! Greetings, Steffen (In reply to comment #2) > Thanks for reporting, I was able to get lu_zero rewriting the altivec code so > that it works correctly, so it's fixed in -r11 now. > |