devkitPro

It's difficult to say without further information and, unfortunately, we don't really have the time to examine large projects in any detail. The issue is likely to be related to some code which is interpreted differently with the latest gcc version. The first thing I'd do with a problem like this is...

This isn't really a bug as such, the template doesn't use libm so it wasn't added to the libraries in there. I might as well just add it to the template though, it's likely that most cube/wii code will be using libm functions eventually. Just add -lm to the LIBS line in the makefile like this :- #--...

Is there any reason why you want to worry about allocating the memory "nicely"? libogc apps manage their own memory pool so really it doesn't matter how you allocate things in a launcher. Personally I'd tend to just load the new app being launched straight to where it's supposed to go &...

That might be a useful feature to have actually. You can adjust the stack size per thread using LWP_CreateThread though and, fwiw, the main function in a libogc app is actually the first thread started by the microkernel. So, something like this will let you manage the stack size in your code. stati...

Well, yeah. You should be using the scanpads function or at least providing the same functionality we have in there now. That's one of those lot check items commercial games have to deal with too - input failure after replugging pads is a big no no.

The unmount solution seems good to me, I've changed that in CVS now. Thanks.

Fixed in CVS, thanks for that.

Definitely not your bug. I found some old default newlib code in the malloc support functions - not really sure why the default behaviour is to abort on failure tbh. Fixed in CVS, hopefully won't be too much longer before we get the next toolchain iteration out there.

We'll need a testcase I think, currently this works for me although I'm using current CVS & the next toolchain iteration.

.data is already in ewram. My .map file seems to disagree with you: Heh, that's what I get for relying on memory & not going back to check the linkscripts before responding. Actually .data probably would be better off in ewram instead. I'm not so sure about bss, it really depends on how people ...