On Mon, Feb 17, 2014 at 11:43:16AM +0100, Thomas Orgis wrote: >Am Mon, 17 Feb 2014 10:00:48 +0200 >schrieb Riku Voipio <riku.voi...@iki.fi>: > >> Thanks Peter for explaining, this was how I ended up the suggestion >> in the bug. >> >> > I see. In that case, I'll have to leave the package as it until >> > something along those lines is implemented. >> >> Yes. The ideal solution is for the upstream to implement cpu runtime >> detection that: >> >> 1) uses neon if it is available >> 2) falls back to fixed point if app requested 16-bit playback >> 3) finally falls back to generic fpu code if neither of above applies >> >> Any packaging level workaround is going to be suboptimal for someone. > >Isn't the approach for the linker to select libraries like libavcodec >on the table anymore? I see that I'll have to add that float conversion >code to keep the features along all builds, but selecting a vfp and >non-vfp variant for fixed point or floating point via the linker seems >like the most clean approach you are going to get.
Yes, you can do that - build several copies of the library and use the hwcaps / auxv approach to pick the best one for the hardware at link time. >NEON detection may come... but if we have linker selection, that would >be covered right now. Yup. -- Steve McIntyre, Cambridge, UK. st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140217123430.ga12...@einval.com
