Rockbox mail archiveSubject: Re: 540e5d1: Forget about fixedpoint.c in any HWCODEC bin.
Re: 540e5d1: Forget about fixedpoint.c in any HWCODEC bin.
From: Michael Sevakis <jethead71_at_sbcglobal.net>
Date: Tue, 16 Apr 2013 11:03:04 -0400
> Hmm, how can that happen? Creating a libX.a is just packing *.o into an
> archive, regardless of internal references. It doesn't even involve the
When linking the binary it does, and since the linker sees no referenences
(libfirmware.a is linked in earlier than rbcodec.lib), it discards it. I
verified that the fixedpoint functions were present in the libfirmware
archive. Reversing the lib linking order just causes the same sort of issues
with other libs.
> If codeclib (from /lib/rbcodec), which we ideally want to work outside
> Rockbox, uses this then fixed point should also be somewhere in /lib IMO.
What does work is building fixedpoint.c as part of rbcodec, not the binary.
That in addition to moving fixedpoint.h to /lib and /lib as an include path
wraps it up nicely. Even though I would like to do so, it can't be a
globally used archive because of the different compilation conditions for
core, plugin and codec.
Received on 2013-04-16