Search results

I'm usually kicking around efnet on #dsdev, #gbadev, #gp32dev, #gcdev & #gp2xdev

You're using the gp32_sdk.specs file, right? in the gp32_sdk.ld file, found in /path/to/devkitARM/arm-elf/lib, add *(.bss*) to the .bss section after *(COMMON) .bss ALIGN(4) : { __bss_start = ABSOLUTE(.); /* __bss_start__ = ABSOLUTE(.); */ *(.dynbss) *(.gnu.linkonce.b*)...

remove the -s and put the -g there instead. -s strips the debug info. The -g may work where it is but the gcc driver will pass it on to the linker without having to specify it as part of the linker command line. Any particular reason for using the gp32 SDK *and* libmirko?

Why cygwin? devkitARM is designed not to need it. The only advantage you get from cygwin is the ability to build *nix centric code on windows with little or no modification. I'm not sure what you mean. The stub works with the standard USB cable afaik.

It might, it might not - I tried this a long time ago when I put together the first no cygwin toolchains and things died quite badly in places. It might work now. Cygwin is a full posix emulation layer designed to allow easy porting of linux software. This makes it slow and bloated. Msys is a...

No actually, you wouldn't. There are many reasons why this is a bad idea. For historical reasons GCC produces soft float objects which are marked as hard float and actual fpu code is only produced when the -mhard-float switch is used. Building a toolchain which defaults to -msoft-float causes...

That's a weird one, what OS are you using? devkitARM release 18 contains elf2flt for creating BFLT binaries which involves some script hackery with the linker. You can rename ld in that folder and move ld.real.exe back to ld.exe which should get back to the old behaviour. What version of make...

The problem is obviously in the latch_loadsprites function, the assembly you've pasted shows that the compiler places the argument to latch_loadgraphics in r4 then loads r0 from r4 before calling each function. Somewhere in loadsprites r4 is being trashed with O1+. Pasting the assembly for that...

You'd be much better off using msys as specified in the setting up instructions http://www.devkitpro.org/setup.shtml msys gives you a whole bunch of other nix like tools and keeps your machine free of all that cygwin business.

bit like this really http://www.devkitpro.org/visual-c++-express.shtml CodeBlocks doesn't work last I checked (the makefile project stuff wasn't working) and dev C++ isn't great. Personally I prefer IDEs that don't attempt to do everything for you, it's much easier to use them with new...

You use the toplevel bin folder which holds the arm-linux variants of the binaries. The sysroot folder contains glibc 2.3.5 You ignore the many include and lib folders, the compilers know where they are and how to use them. This is a first cut candidate release mainly for testing purposes...

Yes, it does :) Thanks muchly, just received notification from SF, looks like it's just a bit slow in getting through the system.

After a lot of blood, sweat, tears, hair ripping and threatening glibc with a large hammer I've finally managed to produce a windows hosted arm linux toolchain. The build is provided as a self extracting 7zip archive for those brave enough to test...

Use the specs files provided for linking, use gcc/g++ to link and add -specs=gp32.specs to the parameters. This provides a gp32 linkscript and crt0 have a look at the gp32 example code for some useful templates. http://sourceforge.net/project/showfiles.p...lease_id=365156

devkitARM has been updated to gcc 4.0.2. There are also updates to libnds, libgba and the respective examples. http://www.devkitpro.org

Have you got something installed that hides the referrer? The site has hotlink protection enabled.

I'm working on fixing this one. MrMirko's method of overriding standard library functions using #defines doesn't work. all of these errors are due to using gcc to link a C++ project. Using arm-elf-g++ to compile and link will fix them all. I've mailed you a makefile which builds your project...

I have absolutely no idea where you got that idea from. // works fine

This uses devkitARM, see http://www.devkitpro.org

uh, #include <name>_<extension>.h ? i.e. #include "name_bin.h", or <name_bin.h> which searches specified include folders first.