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
> linker.
>

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.

Mike
Received on 2013-04-16