The version of libfxcg I'm using has a libc which has printf and friends broken for certain types of numbers. This libc is the same that is on Jonimoose's repo.

Numbers are completely broken but there are problems with the output in general, too - even if less frequent. But numbers do not output at all:


Most often numbers simply get replaced by a forward slash (situation not shown above). If the output is meant to be, for example, "tan(1)", it becomes "tan(/)". But then there are times where it is preceded by junk.

Strings without numbers sometimes output right, other times have leading spaces that shouldn't have and sometimes show junk:


I know AHelper has uClibc implemented on his libfxcg fork, and even though I can compile it (with lots of warnings), when I try to use it, the linker complains:

Code:


I think KermM solved some of the issues with printf so that LuaZM would work properly. But again, the fixed code is nowhere to be seen.

It's really annoying to have gone past lots of compiling trouble, and then when I have a almost-functioning add-in, I get these kinds of problems... I'm already tired of debugging problems that aren't related to my code or the code I'm porting... any suggestions on what can be done to get this working?

I didn't solve any issues in the core uclibc printf, sadly, and I haven't republished much of my LuaZM code because it's a mess of different licenses that I need to reconcile. If there's anything I can do to help you get what you're using working, I'd be happy to. Sadly, I don't remember getting those linking errors from uclibc. What we really need is a decent subset of stdlib in libfxcg, which is much easier said than done.

Does LuaZM use AHelper's port of uclibc, or are you using the fairly basic printf from the original libfxcg which barely implements less than half of the formatting workers (from what I could see)?

uclibc seems complete in terms of printf, but then I get those errors which I can't solve. I have looked to the code in uclibc which supposedly is causing it, and I have no idea why it happens. In fact, I never saw a strnlen implementation on the Prizm, but about the other undefined reference I have no idea.

EDIT:
floats look like this:

There's a lot of stuff missing from the libfxcg printf implementation because I have any number of things to work on, and the legwork of implementing format specifiers is way down my priority list. If there are specific formats you need, I might be convinced to add them for you or point you at the way to go about implementing them.

As for why it doesn't work, it seems to be a platform issue. It's very hard to say what exactly is wrong because we have no sensible way to debug. What I do know is that it works properly when tested on 64-bit Linux (see libc/tests/printf), and a cursory test (well, hack really) targeting 32-bit Windows (cross-compiling with gcc and running under wine) isn't quite right:
Code:

The wrong display looks like bad reads on the stack, which could conceivably be a similar issue to the Windows target. I'll have to investigate further.

EDIT
gcc -m32 exhibits the same test failure ("1.. 1.. 1.. YAY!") as i486-mingw-32-gcc, so it seems to be a quirk of x86_64 that it worked at all on 64-bit Linux.
Turns out I was depending on undefined behavior in va_arg where passing a va_list by value then reusing that value later is unspecified.
I've committed a fix that makes the test pass with gcc -m32, so that will hopefully fix some of your problems on-calc.

Yeah, that looks familiar when I was working on it. puts_unlocked and strnlen are required by uclibc, I added them myself:


Code:


And uclibc does work: