GP32 Gp32 Sdk Gcc Libs For Armdevkit R19


slaanesh posted on Sep 30 2006 at 02:31 AM said:
Just wondering if there are any chance of getting the GP32 SDK libraries compiled under DevKitArm R19 so that that I can build my project?

Or am I stuck with R18 now?

I do not know if you guys have source to this library but if you do just recompile. Of course that is too simplistic a statement. I just spent 4 days rebuild the GP2X environment and libraries on my linux box and I still can't link some project on my windows box (so I have given up on the wondows GP2X developement for now). I use my R19 stuff for Nintendo DS and Game Boy Advance and I have some libraries that are not in EABI format so I can no longer use them.
 
Last edited by a moderator:
That's the thing - I don't have source to the GP32 SDK libraries - though I'm sure someone does?

They need to be recompiled with DevkitARM R19 so that I can use R19 to compile...
 
slaanesh posted on Sep 30 2006 at 09:37 PM said:
That's the thing - I don't have source to the GP32 SDK libraries - though I'm sure someone does?

They need to be recompiled with DevkitARM R19 so that I can use R19 to compile...

If I had them I would do the recompile but I don't have them either.
 
Last edited by a moderator:
slaanesh posted on Oct 1 2006 at 02:37 AM said:
That's the thing - I don't have source to the GP32 SDK libraries - though I'm sure someone does?

They need to be recompiled with DevkitARM R19 so that I can use R19 to compile...

GP32 EABI Libs

There you go :). Work fine with the EABI markings on R19 upwards, use them myself ;). Put them over the top of the libs you used with R18 and lower (also my patched ones IIRC).

If you understand why DKArm switched to EABI you would realise it was the only sane choice to keep things maintainable.

There is also loads of info in the DKArm docs about EABI support and what to do if you can’t get EABI formatted libs (of more interest to the GBA/DS types as the only missing GP32 libs are in this post ;)).
 
Last edited by a moderator:
DJWillis posted on Oct 2 2006 at 07:47 AM said:
There you go :). Work fine with the EABI markings on R19 upwards, use them myself ;). Put them over the top of the libs you used with R18 and lower (also my patched ones IIRC).
Ripper! :D Thanks a bunch! I'll try them as soon as I get home tonight!

EDIT: Works great. Thanks!
 
Last edited by a moderator:
*raises glass* cheers to DJWillis for all that crazy stuff you do to keep us in the good... and happy ;)

I'll give this a look a little later tonight hopefully, between college and work I've been left with little to no time at all...
 
Hi. I am new to this forum, and new also to GP32. Although I thought that this machine was already forgotten, I've seen some recent posts showing that its not all true so I am now a little relieved because I will be able to get my development tools ready. Having into account that www.gpeu.com is no more or at least seems not to work, and that the official page of gp32 has no links to sdk and tools, I downloaded them by other ways.

What I was lacking was just eabi libraries. Finally thanks to DJ Willis I got them.

Anyway I have some initial questions:

1.- DJ Willis. Where did you get the source code? Can it be released? I am just curious.
2.- What are STD libraries used for? To build with Visual C++?

Thanks in advance.
 
Anyway I have some initial questions:

1.- DJ Willis. Where did you get the source code? Can it be released? I am just curious.
2.- What are STD libraries used for? To build with Visual C++?

Thanks in advance.

Hiya,

Nice to see new GP32 devs about, it gets less attention these days but that does not mean we should confine it to the bin just yet :D.

1: Afraid not :(.

2: There are versions of the SDK compiled as a wrapper for Visual C++ that GamePark did very early on in the GP32's life but believe me it is more effort then it is worth and the results are very very inconsistent with real hardware (it was a subset of the full SDK for example) and very limited compared to using the SDK to target real hardware or GeePee.
 
Last edited by a moderator:
Don't know if it matters but the R19 kit has a utility script and program that will extract the object file from a library and convert the to the eabi format. I did this from some libraries I did not have the source to.

Thanks, this is good to know!

By the way, if a moderator is listening, is there any chance that you can change the topic to read "DevKitArm R19" instead of "Armdevkit R19"?
I think I originally wrote this plea after I'd been drinking or something. :)
 
Last edited by a moderator:
To DJWillis.

There are still some reminiscences of the old DevKit ARM in your new SDK

CC = arm-elf-gcc
CXX = arm-elf-g++
LD = arm-elf-gcc
AS = arm-elf-as
OBJCOPY = arm-elf-objcopy

is found in gp32_gpsdk.mk file on the root of your released sdk for eabi.

Just found that it would interest you to correct this.

Anything that I find odd or any doubts I have will be posted here. I thank you in advance for your appreciated help.
 
Can somebody tell my why this happens?

$(CC) -o $@ $(STARTUP_CODE_FILEPATH) $(OBJ_FILES_FULL) $(LDFLAGS)

works, but

$(CC) $(LDFLAGS) -o $@ $(STARTUP_CODE_FILEPATH) $(OBJ_FILES_FULL)

don't.

If libraries (whith other linker parameters in LDFLAGS) are specified after gpmain.o and code objects, the linker fails showing unresolved symbols for each call to a function library.

I think this has to do with some bug in the DevKitARM, so maybe this post has not to be written here. I'll try to post this also in DevKitARM.

I know that having a workaround I should not bother developers with theese things, but is something that I consider should be corrected or documented.

Thanks anyway.
 
Anyway I have some initial questions:

1.- DJ Willis. Where did you get the source code? Can it be released? I am just curious.
2.- What are STD libraries used for? To build with Visual C++?

Thanks in advance.

You could try emailing Gamepark and asking for the sdk source, you might get lucky.
 
Last edited by a moderator:
Can somebody tell my why this happens?

$(CC) -o $@ $(STARTUP_CODE_FILEPATH) $(OBJ_FILES_FULL) $(LDFLAGS)

works, but

$(CC) $(LDFLAGS) -o $@ $(STARTUP_CODE_FILEPATH) $(OBJ_FILES_FULL)

don't.

If libraries (whith other linker parameters in LDFLAGS) are specified after gpmain.o and code objects, the linker fails showing unresolved symbols for each call to a function library.

I think this has to do with some bug in the DevKitARM, so maybe this post has not to be written here. I'll try to post this also in DevKitARM.

I know that having a workaround I should not bother developers with theese things, but is something that I consider should be corrected or documented.

Thanks anyway.
Not sure this will apply to the issue you have or the stage (compile or link) you are trying to accomplish. I will assume you are trying the link stage. The compiler gcc /g++/others will call the linker binary to accomplish the link stage. The compiler will filter some of the flags and passes the ones it thinks need to be passed to the linker. The position on the command line may influence what the compiler needs to pass to the link stage. There are ways of forcing switch values to be passed to the link stage (based on the compiler documentation) that can used. I "think" the positioning of the LDFLAGS value is influencing the compiler's guess as to which stage the values should be passed to. Of course I could be wrong in your case but I have had this kind of issue.
 
Last edited by a moderator:
As you said is the linking stage. I wanted to use LD instead of CC for linking, but specs cannot be passed to ld and have to be passed to gcc. As I don't know what specs file is used for I used gcc for linking as in the examples.

Anyway until I know something more about specs and other aspects of the toolchain I will keep this way as it works.
 
Yeah! Today I reinstall devkitpro with eabi, tried to compile old projects, found out the GP32SDK was conflicted. Then I said I am busted :p (or I could switch to mr mirko libs).
But now I find this. First the EABI versions of GP32SDK and then the link to the tool (because I also was using CHN modplayer, there could be problems there too).
But now I am at the office, so I will continue GP32 coding tonight hopefully.. (I really can't wait)
 
Back
Top