Somewere between revision 16 and revision 22, the compiler prefix changed from powerpc-gekko-xxx to powerpc-eabi-xxx.
I am trying to compile scummvm, which is still based on the revision 16 toolchain.
I tried to locate that older toolchain, but in sourceforge, I can only locate the older revisions 21 and 20.
Also, they don't add the makefiles anymore. They assume you should run ./configure which creates that makefile for you.
Is this suposed to work in a windows environment with msys?
After a couple of fustrating days, it finally compiles, but the resulting dol simply gives me an exception.
I linked it to some precompiled libraries, which are almost sure compiled with the older toolchain.
Should those libs be compatible if they are linked with the newer toolchain?
I realise I can locate what causes the excption with gdb, if the sources are compiled without optimalisations and with the debug flag set.
Should I compile all the used libraries with those settings as well?
I don't have a usb gecko debug adapter. I assume it would make my life a bit easier, but I think the optimalisation settings need to be turned off as well to have it work properly.
Are there descriptions somewhere about what needs to be done to convert code from older toolchains to the newest?
devkitppc revisions
-
WinterMute
- Site Admin
- Posts: 1911
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: devkitppc revisions
the configure stuff should work fine with msys with a couple of minor tweaks. I'm attempting a scummvm build locally - the build works on OSX fine, can't seem to manage to get it launched, either via wiiload or HBC. Not quite sure what's going on there.
I'm attempting a build on windows now which I'll post some notes for here :-
First thing you'll need is git for obtaining the libgxflux sources - http://code.google.com/p/msysgit/ . I used the netinstall version which takes a bit of time to sort out. Once it's done, it will launch an msys shell for git - from there cd to a suitable directory & type git clone git://repo.or.cz/libgxflux.git. I patched this for latest tools as follows :-
Then simply make install should give you the wii & cube versions of libgxflux.
Grab the svn trunk of ScummVM and patch as follows :-
You'll need to add some libraries from portlibs - zlib & libtremor, see http://devkitpro.org/wiki/portlibs
use the configure line CPPFLAGS=-I$DEVKITPRO/portlibs/ppc/include LDFLAGS=-L$DEVKITPRO/portlibs/ppc/lib ./configure --host=wii
So far I haven't been able to get the binary to launch, not quite sure why yet. There was some discussion on IRC recently about HBC not shutting down the network properly before launching a dol which causes random errors.
If you get anywhere let me know.
I'm attempting a build on windows now which I'll post some notes for here :-
First thing you'll need is git for obtaining the libgxflux sources - http://code.google.com/p/msysgit/ . I used the netinstall version which takes a bit of time to sort out. Once it's done, it will launch an msys shell for git - from there cd to a suitable directory & type git clone git://repo.or.cz/libgxflux.git. I patched this for latest tools as follows :-
Code: Select all
diff --git a/common.mk b/common.mk
index 4e5dba2..7aadffc 100644
--- a/common.mk
+++ b/common.mk
@@ -1,4 +1,4 @@
-PREFIX ?= $(DEVKITPPC)/bin/powerpc-gekko-
+PREFIX ?= $(DEVKITPPC)/bin/powerpc-eabi-
AR = $(PREFIX)ar
AS = $(PREFIX)as
Grab the svn trunk of ScummVM and patch as follows :-
Code: Select all
Index: configure
===================================================================
--- configure (revision 54217)
+++ configure (working copy)
@@ -1007,7 +1007,7 @@
gamecube)
_host_os=gamecube
_host_cpu=ppc
- _host_alias=powerpc-gekko
+ _host_alias=powerpc-eabi
;;
gp2x)
_host_os=gph-linux
@@ -1122,7 +1122,7 @@
wii)
_host_os=wii
_host_cpu=ppc
- _host_alias=powerpc-gekko
+ _host_alias=powerpc-eabi
;;
wince)
_host_os=wince
Index: backends/platform/wii/main.cpp
===================================================================
--- backends/platform/wii/main.cpp (revision 54217)
+++ backends/platform/wii/main.cpp (working copy)
@@ -221,7 +221,7 @@
printf("shutdown\n");
SYS_UnregisterResetFunc(&resetinfo);
- fatUnmountDefault();
+ //fatUnmountDefault();
if (res)
show_console(res);
Index: backends/platform/wii/osystem_events.cpp
===================================================================
--- backends/platform/wii/osystem_events.cpp (revision 54217)
+++ backends/platform/wii/osystem_events.cpp (working copy)
@@ -185,7 +185,7 @@
_padAcceleration = 9 - ConfMan.getInt("wii_pad_acceleration");
#ifdef USE_WII_KBD
- _kbd_active = KEYBOARD_Init() >= 0;
+ _kbd_active = KEYBOARD_Init(NULL) >= 0;
#endif
}
Index: backends/platform/wii/wii.mk
===================================================================
--- backends/platform/wii/wii.mk (revision 54217)
+++ backends/platform/wii/wii.mk (working copy)
@@ -17,10 +17,10 @@
$(DEVKITPPC)/bin/geckoupload $<
wiigdb:
- $(DEVKITPPC)/bin/powerpc-gekko-gdb -n $(EXECUTABLE)
+ $(DEVKITPPC)/bin/powerpc-eabi-gdb -n $(EXECUTABLE)
wiidebug:
- $(DEVKITPPC)/bin/powerpc-gekko-gdb -n $(EXECUTABLE) -x $(srcdir)/backends/platform/wii/gdb.txt
+ $(DEVKITPPC)/bin/powerpc-eabi-gdb -n $(EXECUTABLE) -x $(srcdir)/backends/platform/wii/gdb.txt
# target to create a Wii snapshot
wiidist: all
use the configure line CPPFLAGS=-I$DEVKITPRO/portlibs/ppc/include LDFLAGS=-L$DEVKITPRO/portlibs/ppc/lib ./configure --host=wii
So far I haven't been able to get the binary to launch, not quite sure why yet. There was some discussion on IRC recently about HBC not shutting down the network properly before launching a dol which causes random errors.
If you get anywhere let me know.
Re: devkitppc revisions
First of all, many thanks for looking into this.
I managed to compile the sources, but the resulting dol isn't running. It gives a dsi exception screen.
I tried to locate the origin of it using gdb, but it doesn't give any usefull information. It says the error is in the show_console function of main.cpp.
I tried to find out how far the code runs into the main function by adding an exit(0);
A very strange thing is that this addition causes the gxflux library to give me an unresolved external error in gfx.c. I added a small function to that gfx.c to get rid of an unresolved "round" function.
double round(double x){
return(floor(x+0.5));
}
When I add the exit(0) to the main.c, the linker starts complaining about floor being an unresolved external.
I checked the makefile, and the math library is linked. I found it even strange that round gave me an unresolved external in the first place. I think I have a wrong version of the gxflux lib or an issue in the makefile of it.
You are telling me that you can't launch the binary either?
Is it also giving you an exception screen?
If the issue would be HBC not closing it's network stack properly, shouldn't copiing the dol to the sd solve it?
I am considering to contact the original porter and maintainer of the scummvm_wii. I was told to do so on the Scummvm forum.
First off all, I would like to get better information about the program flow.
Where are the printf messages going to, and can I capture them over the network or in a file or something like that?
Do you know if the usb gecko debug adapter can still be purchased?
The new website (www.usbgecko.com) doesn't look very functional yet which frightens me a bit.
I managed to compile the sources, but the resulting dol isn't running. It gives a dsi exception screen.
I tried to locate the origin of it using gdb, but it doesn't give any usefull information. It says the error is in the show_console function of main.cpp.
I tried to find out how far the code runs into the main function by adding an exit(0);
A very strange thing is that this addition causes the gxflux library to give me an unresolved external error in gfx.c. I added a small function to that gfx.c to get rid of an unresolved "round" function.
double round(double x){
return(floor(x+0.5));
}
When I add the exit(0) to the main.c, the linker starts complaining about floor being an unresolved external.
I checked the makefile, and the math library is linked. I found it even strange that round gave me an unresolved external in the first place. I think I have a wrong version of the gxflux lib or an issue in the makefile of it.
You are telling me that you can't launch the binary either?
Is it also giving you an exception screen?
If the issue would be HBC not closing it's network stack properly, shouldn't copiing the dol to the sd solve it?
I am considering to contact the original porter and maintainer of the scummvm_wii. I was told to do so on the Scummvm forum.
First off all, I would like to get better information about the program flow.
Where are the printf messages going to, and can I capture them over the network or in a file or something like that?
Do you know if the usb gecko debug adapter can still be purchased?
The new website (www.usbgecko.com) doesn't look very functional yet which frightens me a bit.
-
WinterMute
- Site Admin
- Posts: 1911
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: devkitppc revisions
I don't get an exception, just a blank screen when I run via wiiload. Loading from SD just seems to stall which may be related to the sd card itself, not really sure what's going on atm.
Dhewg hasn't been seen online in a while unfortunately.
Hopefully when you refer to main.c you actually mean main.cpp, I don't see a main.c file and I definitely don't get unresolved externals when adding an exit function. You're definitely using scummvm trunk? Are you using libraries compiled with different toolchain versions?
Ian is still getting set up for selling usbgecko SE so things look a little unfinished atm, it's nothing to worry about.
Dhewg hasn't been seen online in a while unfortunately.
Hopefully when you refer to main.c you actually mean main.cpp, I don't see a main.c file and I definitely don't get unresolved externals when adding an exit function. You're definitely using scummvm trunk? Are you using libraries compiled with different toolchain versions?
Ian is still getting set up for selling usbgecko SE so things look a little unfinished atm, it's nothing to worry about.
Re: devkitppc revisions
Sorry, my mistake, I did mean the main.cpp in the backends\platform\wii folder.
I am using the scummvm trunk.
Some of the libraries come from a packaged proposed in the how to compile wiki for wii.
I didn't recompile those myself, so they might be from an older toolchain.
I believe it are the portlibs: z , mad, vorbisidec and flac.
I resolved one of my unresolved external mysteries. My makefile comes from an older build that didn't need the gxflux library. Being a noob in gcc compiling, I added that library to the end of the libchain.
If I add it before the ogc and m lib, the unresolved externals in that lib are gone.
Considering my exception:
If my understanding of the code is right, upon an error, the console window is shown with all the printf stuff from during execution. In the show_console function (main.cpp in wii folder), there is a _break(); when the DEBUG_WII_GDB is set. This is not the case in my build. It probably is in your build explaining why it doesn't reach the exception. I will try a build without that console showing up and see what it does.
There is one other thing I still don't get.
If I remark the "res = scummvm_main(argc,argv);" (in the main function of main.cpp in wii folder),
I get a bunch of errors when I try to build (just using the make command).
If I remove that line using the following code, there is no problem.
//should always be included in code, even with optimalisations turned on.
dummy = 0;
if(dummy == 1)
{
res = scummvm_main(argc,argv);
}
res = 32; //to force the console screen to be shown.
Do you know why my linking fails if I simply remark that line?
I will try to get that console stuff going first, as without it, I have no feedback at all from the program flow.
Thanks again that you are willing to help, and sorry for the long posts.
I am using the scummvm trunk.
Some of the libraries come from a packaged proposed in the how to compile wiki for wii.
I didn't recompile those myself, so they might be from an older toolchain.
I believe it are the portlibs: z , mad, vorbisidec and flac.
I resolved one of my unresolved external mysteries. My makefile comes from an older build that didn't need the gxflux library. Being a noob in gcc compiling, I added that library to the end of the libchain.
If I add it before the ogc and m lib, the unresolved externals in that lib are gone.
Considering my exception:
If my understanding of the code is right, upon an error, the console window is shown with all the printf stuff from during execution. In the show_console function (main.cpp in wii folder), there is a _break(); when the DEBUG_WII_GDB is set. This is not the case in my build. It probably is in your build explaining why it doesn't reach the exception. I will try a build without that console showing up and see what it does.
There is one other thing I still don't get.
If I remark the "res = scummvm_main(argc,argv);" (in the main function of main.cpp in wii folder),
I get a bunch of errors when I try to build (just using the make command).
If I remove that line using the following code, there is no problem.
//should always be included in code, even with optimalisations turned on.
dummy = 0;
if(dummy == 1)
{
res = scummvm_main(argc,argv);
}
res = 32; //to force the console screen to be shown.
Do you know why my linking fails if I simply remark that line?
I will try to get that console stuff going first, as without it, I have no feedback at all from the program flow.
Thanks again that you are willing to help, and sorry for the long posts.
-
WinterMute
- Site Admin
- Posts: 1911
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: devkitppc revisions
This is probably your main issue
Your makefile needs to be generated from configure and not copied from an older build, this is pretty much guaranteed to cause problems.
To make sure you're not having problems with mismatched libraries I'd suggest deleting the libogc folder and editing the installed.ini file to force a reinstall of the official libraries. In the installed.ini file (found in your devkitPro folder) change the version numbers of libogc and libogcfat - anything will do as long as it doesn't match the current versions. Run the updater and let it do it's thing.
Create portlibs/ppc in your devkitPro folder, download zlib-1.2.4-ppc.tar.bz2 & tremor-lowmem-ppc.tar.bz2 from http://sourceforge.net/projects/devkitp ... /portlibs/. Extract these into the portlibs/ppc folder.
Clean your scummvm checkout - i.e. make clean then make sure it's up to date then follow the instructions in my earlier post to install libgxflux. Patch your scummvm source then run the configure line from an msys shell - I think you need to have devkitPPC in the path for that to work, i.e. export PATH=$DEVKITPPC/bin:$PATH first.
libmad is provided along with libogc so you probably shouldn't be using an alternative version. zlib used to be provided that way & may still exist in your libogc folder but shouldn't matter too much. vorbisdec is the float version of tremor I think, not sure if that's significantly better than vorbisidec (tremor-lowmem).Some of the libraries come from a packaged proposed in the how to compile wiki for wii.
I didn't recompile those myself, so they might be from an older toolchain.
I believe it are the portlibs: z , mad, vorbisidec and flac.
I resolved one of my unresolved external mysteries. My makefile comes from an older build that didn't need the gxflux library.
Your makefile needs to be generated from configure and not copied from an older build, this is pretty much guaranteed to cause problems.
To make sure you're not having problems with mismatched libraries I'd suggest deleting the libogc folder and editing the installed.ini file to force a reinstall of the official libraries. In the installed.ini file (found in your devkitPro folder) change the version numbers of libogc and libogcfat - anything will do as long as it doesn't match the current versions. Run the updater and let it do it's thing.
Create portlibs/ppc in your devkitPro folder, download zlib-1.2.4-ppc.tar.bz2 & tremor-lowmem-ppc.tar.bz2 from http://sourceforge.net/projects/devkitp ... /portlibs/. Extract these into the portlibs/ppc folder.
Clean your scummvm checkout - i.e. make clean then make sure it's up to date then follow the instructions in my earlier post to install libgxflux. Patch your scummvm source then run the configure line from an msys shell - I think you need to have devkitPPC in the path for that to work, i.e. export PATH=$DEVKITPPC/bin:$PATH first.
Re: devkitppc revisions
Following your instructions to the letter:
$ CPPFLAGS=-I$DEVKITPRO/include/portlibs/ppc LDFLAGS=-L$DEVKITPRO/portlibs/ppc/
lib ./configure --host=wii
Running ScummVM configure...
Looking for C++ compiler... c:/devkitpro/devkitppc/bin/powerpc-eabi-g++
Checking for compiler version... 4.5.1, ok
Checking for whether -Wglobal-constructors work... no
Checking endianness... ./configure: line 1350: strings: command not found
little
Type with 1 byte... char
Type with 2 bytes... couldn't find data type with 2 bytes
I don't even get how it could possibly run this checks, as we are using a cross compiler?
So, I modified the configure file a little:
if test "$datatype" = "unknown"; then
echo "couldn't find data type with $1 bytes"
#exit 1
fi
continue
fi
done
This made it finish it's job. It just hadn't filled in the datatypes in the config.h file correctly.
So, I tweaked those manually as well.
I know it's not decent programming work.
I get a lot of warnings about int32 and uint32 that should be int. I don't mind using int instead of int32, but the conversion from uint32 to int doesn't seem a proper practice.
Could you give me the correct values for signed and unsigned 16 and 32 bit values from the config.h file?
Do you have any idea why I am having this behavour when I run the configure?
If I get things running, I will write a little how to tutorial for people trying to follow my footsteps.
$ CPPFLAGS=-I$DEVKITPRO/include/portlibs/ppc LDFLAGS=-L$DEVKITPRO/portlibs/ppc/
lib ./configure --host=wii
Running ScummVM configure...
Looking for C++ compiler... c:/devkitpro/devkitppc/bin/powerpc-eabi-g++
Checking for compiler version... 4.5.1, ok
Checking for whether -Wglobal-constructors work... no
Checking endianness... ./configure: line 1350: strings: command not found
little
Type with 1 byte... char
Type with 2 bytes... couldn't find data type with 2 bytes
I don't even get how it could possibly run this checks, as we are using a cross compiler?
So, I modified the configure file a little:
if test "$datatype" = "unknown"; then
echo "couldn't find data type with $1 bytes"
#exit 1
fi
continue
fi
done
This made it finish it's job. It just hadn't filled in the datatypes in the config.h file correctly.
So, I tweaked those manually as well.
I know it's not decent programming work.
I get a lot of warnings about int32 and uint32 that should be int. I don't mind using int instead of int32, but the conversion from uint32 to int doesn't seem a proper practice.
Could you give me the correct values for signed and unsigned 16 and 32 bit values from the config.h file?
Do you have any idea why I am having this behavour when I run the configure?
If I get things running, I will write a little how to tutorial for people trying to follow my footsteps.
Re: devkitppc revisions
Just a small update. The produced elf is finally running. Sleeping time. Thanks.
-
WinterMute
- Site Admin
- Posts: 1911
- Joined: Tue Aug 09, 2005 3:21 am
- Location: UK
- Contact:
Re: devkitppc revisions
Sorry, made a typo in that post, now corrected, should beobcd wrote:Following your instructions to the letter:
$ CPPFLAGS=-I$DEVKITPRO/include/portlibs/ppc LDFLAGS=-L$DEVKITPRO/portlibs/ppc/
lib ./configure --host=wii
Code: Select all
$ CPPFLAGS=-I$DEVKITPRO/portlibs/ppc/include LDFLAGS=-L$DEVKITPRO/portlibs/ppc/lib ./configure --host=wii
This is due to missing the strings executable, it can be replaced with powerpc-eabi-stringsChecking endianness... ./configure: line 1350: strings: command not found
little
and this is due to using a variable for the results which devkitPPC uses to find the temp directory when compilingType with 1 byte... char
Type with 2 bytes... couldn't find data type with 2 bytes
What it does is compile a test file and check for error output from the compilerI don't even get how it could possibly run this checks, as we are using a cross compiler?
I've created another patch file which fixes all the issues for me when using the msys shell to configure and added this to the scummvm patch tracker at https://sourceforge.net/tracker/?func=d ... tid=418822
libpng-1.4.1-ppc.tar.bz2 from portlibs should also be installed. I'll see if I can make some time to build libflac at some point
Re: devkitppc revisions
You are the best. It compiles without issues after it's patched. I created a document (mostly for my own purpose) describing all the steps that needs to be taken.
(It's not much more than all the steps you gave on this forum, combined with a few tips I find usefull since I am not very familiar with Linux.) I just don't know were to post it to be usefull. Maybe the scummvm wii forum would be a good place, if that's alright for you.
I can finally start searching for the missing cursor in the humonogous scumm games.
I don't think I will succeed before my daughters anniversary party next saturday.
(It's not much more than all the steps you gave on this forum, combined with a few tips I find usefull since I am not very familiar with Linux.) I just don't know were to post it to be usefull. Maybe the scummvm wii forum would be a good place, if that's alright for you.
You didn't make a typo. I did when I retyped in the instructions here. I really should be more carefull when I type.$ CPPFLAGS=-I$DEVKITPRO/include/portlibs/ppc LDFLAGS=-L$DEVKITPRO/portlibs/ppc/
lib ./configure --host=wii
I can finally start searching for the missing cursor in the humonogous scumm games.
I don't think I will succeed before my daughters anniversary party next saturday.
Who is online
Users browsing this forum: No registered users and 1 guest