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
