slaanesh
Certified Guru
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?
Or am I stuck with R18 now?
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?
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...
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...
Ripper! Thanks a bunch! I'll try them as soon as I get home tonight!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).
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.
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.
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.
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.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.