Page 1 of 2
Building PS2 Toolchains In MinGW
Posted: Sun Jul 01, 2007 2:50 am
by Lukasz
Update:
Tutorial and binaries now available at:
http://lukasz.dk/programming/playstatio ... -tutorial/
Original Post:
Today I attempted to build the PS2 Toolchains with ooPo's script in
MinGW and succeeded with some minor modifications to the toolchain. I'm just gonna describe the process briefly, as I'm going on vacation in a few hours. I will probably write up a complete tutorial once I get back in a weeks time, unless someone beats me to it.
First of all you clearly need to install MinGW, MSYS and other tools. I just downloaded everything described in this thread:
http://forum.doom9.org/showthread.php?t=108215
Besides from those tools I also downloaded wget and subversion and manually installed them in the MinGW enviroment. I also renamed rxvt.exe to rxvt2.exe in the MSYS bin directory, to use sh as a shell instead of rxvt.
Then I just did a svn checkout of ooPo's toolchain script in MSYS:
Code: Select all
svn checkout svn://svn.ps2dev.org/ps2/trunk/ps2toolchain
You can add the PS2DEV enviroment variables to msys/1.0/etc/profile.
The binutils for EE, IOP og DVP will build fine, however GCC will fail. In order to fix this you need alter the following file after patching, but before configuring the toolchains. This is not a completely trivial task, so people who are unexperienced with these kind of tasks, might wanna wait for a easier solution.
The file you need to alter is gcc-3.2.2/gcc/fixinc/mkfixinc.sh
Locate the following part of the file, around line 82
Code: Select all
mips-sgi-irix5cross64 | \
powerpc-*-eabiaix* | \
and insert two lines so it now contains this.
Code: Select all
mips-sgi-irix5cross64 | \
mips64r5900el-scei-elf | \
mipsel-scei-irx | \
powerpc-*-eabiaix* | \
This will fix the problem with fixinc (skipping the step), for which there is no MinGW support. More information available here:
http://www.mingw.org/MinGWiki/index.php ... 20compiler
Once you've altered this file, gcc will build for EE and IOP aswell as newlib, ee-g++ and ps2sdk.
Maybe ooPo can include the patch to the mkfixinc.sh in his toolchain patches, if MinGW is detected.
I havn't actually tested any of the ps2sdk samples built these toolchains, as I dont have a PS2 available at the moment, but I dont there should be any problems.
Posted: Tue Jul 03, 2007 9:32 am
by ooPo
If it doesn't affect 'normal' building of the toolchain, I see no reason why it can't be added. Otherwise, we can figure something out. Maybe a separate patch or something...
...anything to get people from using cygwin. :)
Posted: Tue Jul 03, 2007 12:57 pm
by ooPo
I've added it to the gcc patch in the repository, so you should be able to build it on mingw without modification now.
Posted: Tue Jul 03, 2007 11:22 pm
by cosmito
Can one have both MinGW and Cygwin installed at same time without conflicts? I have Cygwin but I would like to evaluate MinGW too.
Posted: Wed Jul 04, 2007 9:37 am
by radad
ptek: That should be no problem.
Lukasz: I would love to have a build of the tools to test out.
Posted: Wed Jul 04, 2007 10:01 am
by cosmito
radad,
I think ragnarok2040 made available a build using MinGW here :
http://forums.ps2dev.org/viewtopic.php?t=6995
A few details :
Precompiled toolchain,
http://d.turboupload.com/d/1219902/ps2dev.exe.html
I've uploaded a ps2 toolchain compiled in mingw, includes a compiled ps2sdk, revision 1358.
Notes about mingw built toolchain:
Patched with the latest patches from the svn repository
IOP toolchain is built with binutils-2.14/gcc-3.2.2, not the older version of the iop toolchain
GCC (all targets) fixinc was not built, it's not needed for anything that's ps2dev dependent
It was also patched with the __restrict enable patch for inline functions, located at
http://forums.ps2dev.org/viewtopic.php?t=4938
Posted: Mon Jul 09, 2007 8:05 pm
by Lukasz
Posted: Mon Jul 09, 2007 9:06 pm
by chp
To get it building under Vista (x86, haven't tested x64), you need to do a few things:
First, you need to use
candidate instead of
current for reasons that come later. If you have installed with current, uninstall and install again with candidate, and follow Lukasz's instructions as normal.
Then, download a new msys-1.0.dll, this will get rid of the heap-issues for all msys binaries:
http://prdownloads.sf.net/mingw/msys-1. ... 2?download
Decompress this with something like WinRAR which supports bzip2 archives, then rename new-msys-1.0.dll to msys-1.0.dll and copy it into C:\msys\1.0\bin (or wherever you installed msys).
After that, go into C:\msys\1.0\postinstall\ and run pi.bat to get the postinstall step properly executed, since it never ran when you first installed (complaining about issues with cygwin heap).
When all of this is done, here's the reason for using
candidate. Download
http://dessent.net/tmp/gcc-vista-3.4.5- ... 7-1.tar.gz and decompress into your MinGW folder. This is to get rid of a nasty bug that causes GCC to not find the compiled backend. (perhaps this file should be given local hosting so we don't exploit some poor souls bandwidth?)
You should now be able to compile ps2toolchain in MinGW under Vista. You do however need to do this in a slightly different fashion than described. To not get build-errors halfway through, instead of:
you write:
Code: Select all
CFLAGS="-D__USE_MINGW_ACCESS" sh toolchain.sh
Even if you build this on XP but intend to use the toolchain under Vista you still need to pass this flag due to a bug with the normal access() called by the gcc frontend.
All done!
Posted: Tue Jul 10, 2007 6:20 pm
by Lukasz
I've updated the tutorial with a notice for Windows Vista and a link to chp's post. I've also mirrored the two files required in the instructions.
Posted: Wed Jul 11, 2007 10:52 am
by radad
I tried option 2 in your tutorial but I didnt install mingw itself.
I get this error:
Code: Select all
ee-gcc -D_EE -G0 -O2 -Wall -I/home/adam/ps2devsrc/ps2sdk/ee/kernel/include -I/home/adam/ps2devsrc/ps2sdk/common/include -I/home/adam/ps2devsrc/ps2sdk/ee/libc/include -I/home/adam/ps2devsrc/ps2sdk/ee/erl/include -Iinclude -DF_sio_init src/sio.c -c -o obj/sio_init.o
In file included from src/sio.c:14:
C:/msys/home/adam/ps2devsrc/ps2sdk/ee/libc/include/stdio.h:21:23: sys/types.h: No such file or directory
ee-gcc is at /usr/local/ps2dev/ee/bin/ee-gcc
and types.h exists in /usr/local/ps2dev/ee/ee/include/sys/
Shouldnt ee-gcc be able to find it there?
Posted: Wed Jul 11, 2007 6:19 pm
by Lukasz
radad wrote:I tried option 2 in your tutorial but I didnt install mingw itself.
Since you didn't install MinGW, I cannot help you, as I did install MinGW and it works for me.
Posted: Thu Jul 12, 2007 11:18 am
by radad
Compiling with the -v option I get this output:
Code: Select all
ignoring nonexistent directory "/usr/local/ps2dev/ee/include"
ignoring nonexistent directory "C:/msys/1.0/local/ps2dev/ee/lib/gcc-lib/ee/3.2.2/include"
ignoring nonexistent directory "C:/msys/1.0/local/ps2dev/ee/ee/sys-include"
ignoring nonexistent directory "C:/msys/1.0/local/ps2dev/ee/ee/include"
I had installed msys to C:\msys and not C:\msys\1.0. I moved the installation to C:\msys\1.0 and it now works. Is there any way to have these paths not hard-coded, relative paths would be much better?
Posted: Thu Jul 12, 2007 1:52 pm
by radad
Also got it working by adding '-isystem $(PS2DEV)/ee/ee/include' to the ee-gcc line. It would be better if we could get that directory embedded in ee-gcc rather than msys converting it to the windows path.
Posted: Sat Jul 14, 2007 3:21 am
by chp
The question is why it is not looking up the directories relative to the gcc executable. I have used the cygwin-build without issues with no cygwin-installation (just a few dlls in the correct location), but from what I can see in procmon it does not even try to look at the relative paths...
As a temporary fix you can add those -isystem parameters to the specs-file and you won't have to pass them on every build.
Posted: Mon Jul 16, 2007 10:25 am
by radad
As a temporary fix I have been using the environment variables:
Code: Select all
export C_INCLUDE_PATH=$PS2DEV/ee/ee/include
export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH:$PS2DEV/ee/include/c++/3.2.2:$PS2DEV/ee/include/c++/3.2.2/ee
The difference with msys is that it modifies the command line parameters for binaries that are not in the /bin directory. In this case when we call mingw with a parameter of /usr/local/ps2dev it changes it to the real directory assuming that the program is a standard win32 binary and doesn't understand the msys directories. Unfortunately this means the real directory is built into the ee-gcc binary.
Posted: Wed Jul 18, 2007 10:31 am
by radad
Tried the gsKit samples last night with this compiler but they were not working. Tracked it down to this function from gsCore.c not returning:
Code: Select all
/// GS CSR (GS System Status) Register
#define GS_CSR (volatile u64 *)0x12001000
/// CSR FINISH Register Access Routine
#define GS_CSR_FINISH ((*GS_CSR) >> 1)&1
void gsKit_finish(void)
{
while(!(GS_CSR_FINISH));
}
Is this working for others? Maybe its the volatile keyword not working?
Posted: Wed Jul 18, 2007 3:42 pm
by ragnarok2040
I wonder if that is the issue I'm currently having with FCEUltra. I ported it using gsKit last year using MinGW around June, but after updating gsKit sometime last year afterwards, it stopped working. I'd forgotten which revision of gsKit I had used. I tracked it down to a function not returning in gs_queue_exec_real(); or gs_queue_exec();, back then, I believe. I'll have to go trace it back down again to make sure.
Posted: Wed Jul 18, 2007 6:40 pm
by Lukasz
radad wrote:Tried the gsKit samples last night with this compiler but they were not working. Tracked it down to this function from gsCore.c not returning:
Code: Select all
/// GS CSR (GS System Status) Register
#define GS_CSR (volatile u64 *)0x12001000
/// CSR FINISH Register Access Routine
#define GS_CSR_FINISH ((*GS_CSR) >> 1)&1
void gsKit_finish(void)
{
while(!(GS_CSR_FINISH));
}
Is this working for others? Maybe its the volatile keyword not working?
Try to disassmble the function when compiled with the MinGW toolchains and whatever toolchains you used before and compare the results, to see if there actually is a difference in codegeneration.
Posted: Thu Jul 19, 2007 11:08 am
by radad
Assembly isn't my strong point but they appear to be exactly the same.
This is what I get from mingw:
Code: Select all
00000230 <gsKit_finish>:
230: 3c031200 lui v1,0x1200
234: 34631000 ori v1,v1,0x1000
238: dc620000 ld v0,0(v1)
23c: 0002107a dsrl v0,v0,0x1
240: 30420001 andi v0,v0,0x1
244: 00000000 nop
248: 1040fffb beqz v0,238 <gsKit_finish+0x8>
24c: 00000000 nop
250: 03e00008 jr ra
254: 00000000 nop
And this is what I get from cygwin:
Code: Select all
00000238 <gsKit_finish>:
238: 3c031200 lui v1,0x1200
23c: 34631000 ori v1,v1,0x1000
240: dc620000 ld v0,0(v1)
244: 0002107a dsrl v0,v0,0x1
248: 30420001 andi v0,v0,0x1
24c: 00000000 nop
250: 1040fffb beqz v0,240 <gsKit_finish+0x8>
254: 00000000 nop
258: 03e00008 jr ra
25c: 00000000 nop
I didn't build either of these compilers so I am not completely sure if they are from the same source.
Posted: Thu Jul 19, 2007 2:02 pm
by radad
I checked out gs_queue_exec_real() as well as it calls gsKit_finish() but they appear to be identical. gsKit_finish appears to be inlined within gs_queue_exec_real and optimized so its difficult to work out what it is actually doing. Some other functions in gsCore are different though.
Posted: Thu Jul 19, 2007 8:55 pm
by Lukasz
The gsKit_finish function waits for the FINISH event interrupt, so either this interrupt is not being generated for some reason or the interrupt is not masked.
If interrupt is not being generated, then there could be problems with the GIF packets, which means any of the functions which generate data for the GIF packet could possibly contain an code(gen) error. Finding this error could take quite a while.
Checking whether the interrupt is masked is easy, this is usually done with the syscall PutIMR. You can also check it by reading the GS IMR register directly.
A very long time ago, I also had toolchain problems, this was in Cygwin though and I dont remember why it happend. The problem was that bitwise shifts over 32 bits would not work correct. So this would be worth checking out. Try to compile and compare asm for something like this:
This could explain the gsKit_finish function not returning, since the GIF packets contain data which is 64 and 128 bit wide, so it is very likely there is some shifting going on somewhere to build the GIF packet. Meaning that the GIF packet is incorrectly built and therefor the GS acts in unpredictable ways.
This was how I discovered the shift bug, as the graphics didn't appear when I build code with the bugged Cygwin toolchain.
Posted: Fri Jul 20, 2007 5:56 pm
by ragnarok2040
I setup a cygwin-hosted toolchain and a mingw toolchain side by side. gsKit works with the cygwin toolchain. The gsKit binary built with the cygwin toolchain works with the mingw toolchain, but it won't work if the mingw toolchain builds gsKit. I'm pretty sure this bug affects p2sdk, too. For a separate project, I've noticed weird errors in regards to u64 sized numbers (I've had to append two 32-bit numbers together by using an array and casting it to u64) and fopen() having trouble opening files from the memory card.
Using your example, the mingw toolchain gives a warning
val64.c:7: warning: left shift count >= width of type
while the cygwin toolchain does not. I don't get any warnings of this type when building gsKit, though.
Code: Select all
#include <stdio.h>
#include <limits.h>
#include <tamtypes.h>
int main() {
u64 val = 0;
val = 1 << 60;
return 0;
}
int value = sizeof(u64) * CHAR_BIT; reports that u64 is 64-bits long
http://rafb.net/p/AU4bbX26.html MingW disassembly
http://rafb.net/p/V5jAIk76.html Cygwin diassembly
I used diff on them but it didn't report any differences except for the filenames.
This might be in relation to bug #3325. The bugs reported in relation to this seem similar.
Posted: Fri Jul 20, 2007 6:55 pm
by Lukasz
ragnarok2040:
Since the the variable val isn't used for anything, the code for the shift is removed (optimized) from the code. What you need to do is call some (dummy) function with the val variable, so that the code for the shift actually gets generated.
Posted: Sat Jul 21, 2007 12:27 am
by ragnarok2040
Using an empty function "void dummy_func(u64 val2) {;}" and calling it in main(); using dummy_func(val); I still end up with the same assembly, though the cygwin tools give out the left shift warning now.
When I used printf("%d",val); (Not correct but it wouldn't error out), the diff output info listed some differences.
http://rafb.net/p/rTG3f633.html
Posted: Sat Jul 21, 2007 8:14 am
by Lukasz
I find it hard to tell what the difference is from the diff output, however it appears that sections of the code are arranged differently for the two toolchains.
This is probably related to the fact that you link against ps2sdk built in MinGW and Cygwin in their respective enviroments and it seems these are different. So if you link against Cygwin ps2sdk (since it is not bugged) in both MinGW and Cygwin, you can get a better idea of what is wrong in the MinGW toolchain.
Is it possible to build a debug version of gsKit? Maybe this would help in finding the bug.
Posted: Sat Jul 21, 2007 2:19 pm
by ragnarok2040
Code: Select all
Initializing the DMAC: RELE=0 MFD=0 STS=0 STD=0 RCYC=0
DMAC Initialized.
Initilizating DMA Channel 2 - GIF
DMA Channel Initialized.
Initilizating DMA Channel 8 - fromSPR
DMA Channel Initialized.
Initilizating DMA Channel 9 - toSPR
DMA Channel Initialized.
NTSC
NTSC
CurrentPointer Before: 0x00000000
CurrentPointer After: 0x00118000
CurrentPointer Before: 0x00118000
CurrentPointer After: 0x00230000
Sending to DMA Channel 2 - GIF
Sent to DMA Channel
CurrentPointer Before: 0x00230000
CurrentPointer After: 0x00270000
Sending to DMA Channel in Chain Mode 2 - GIF
Sent to DMA Channel in Chain Mode
Sending to DMA Channel 2 - GIF
Sent to DMA Channel
Sending to DMA Channel in Chain Mode from UCAB 2 - GIF
Sent to DMA Channel in Chain Mode from UCAB
Sending to DMA Channel in Chain Mode 2 - GIF
Sent to DMA Channel in Chain Mode
Sending to DMA Channel 2 - GIF
Sent to DMA Channel
Here's the gsKit debug output. I removed the output from init code for IOP drivers and from FCEUltra internal stuff. It doesn't look that helpful.
I went through using WinMerge on the disassembly output on gsCore.o. I compiled gsKit with the same cygwin ps2sdk, but with the different toolchains. I'll list the first block of changed assembly. The first paste is Cygwin and the second is Mingw. 1a0: is where the changes start occurring.
Code: Select all
00000158 <gsKit_setactive>:
158: 27bdffe0 addiu sp,sp,-32
15c: ffbf0010 sd ra,16(sp)
160: ffb00000 sd s0,0(sp)
164: 8c820020 lw v0,32(a0)
168: 8c830024 lw v1,36(a0)
16c: 30420001 andi v0,v0,0x1
170: 8c900080 lw s0,128(a0)
174: 00021080 sll v0,v0,0x2
178: 246a003f addiu t2,v1,63
17c: 00441021 addu v0,v0,a0
180: 28660000 slti a2,v1,0
184: 8c450010 lw a1,16(v0)
188: 2469ffff addiu t1,v1,-1
18c: 0146180b movn v1,t2,a2
190: 8c870028 lw a3,40(a0)
194: 00052b42 srl a1,a1,0xd
198: 00031983 sra v1,v1,0x6
19c: 8c880084 lw t0,132(a0)
1a0: 3c021000 lui v0,0x1000
1a4: 0002103c dsll32 v0,v0,0x0
1a8: 34428004 ori v0,v0,0x8004
1ac: 0005283c dsll32 a1,a1,0x0
1b0: fe020000 sd v0,0(s0)
1b4: 00031c38 dsll v1,v1,0x10
1b8: 24020040 li v0,64
1bc: 24e7ffff addiu a3,a3,-1
1c0: 0005283e dsrl32 a1,a1,0x0
1c4: 00073c3c dsll32 a3,a3,0x10
1c8: 00084638 dsll t0,t0,0x18
1cc: fe020018 sd v0,24(s0)
1d0: 00a32825 or a1,a1,v1
1d4: 00094c38 dsll t1,t1,0x10
1d8: 2403000e li v1,14
1dc: 24020041 li v0,65
1e0: 00a82825 or a1,a1,t0
1e4: 01274825 or t1,t1,a3
1e8: fe030008 sd v1,8(s0)
1ec: 2403004c li v1,76
1f0: fe020038 sd v0,56(s0)
1f4: 2402004d li v0,77
1f8: fe030028 sd v1,40(s0)
1fc: fe090030 sd t1,48(s0)
200: fe020048 sd v0,72(s0)
204: fe090010 sd t1,16(s0)
208: fe050040 sd a1,64(s0)
20c: 0c000000 jal 0 <gsKit_vram_alloc>
210: fe050020 sd a1,32(s0)
214: 24040002 li a0,2
218: 0200282d move a1,s0
21c: 0c000000 jal 0 <gsKit_vram_alloc>
220: 24060005 li a2,5
224: dfb00000 ld s0,0(sp)
228: dfbf0010 ld ra,16(sp)
22c: 03e00008 jr ra
230: 27bd0020 addiu sp,sp,32
234: 00000000 nop
00000238 <gsKit_finish>:
238: 3c031200 lui v1,0x1200
23c: 34631000 ori v1,v1,0x1000
240: dc620000 ld v0,0(v1)
244: 0002107a dsrl v0,v0,0x1
248: 30420001 andi v0,v0,0x1
24c: 00000000 nop
250: 1040fffb beqz v0,240 <gsKit_finish+0x8>
254: 00000000 nop
258: 03e00008 jr ra
25c: 00000000 nop
Code: Select all
00000158 <gsKit_setactive>:
158: 27bdffe0 addiu sp,sp,-32
15c: ffbf0010 sd ra,16(sp)
160: ffb00000 sd s0,0(sp)
164: 8c820020 lw v0,32(a0)
168: 8c830024 lw v1,36(a0)
16c: 30420001 andi v0,v0,0x1
170: 8c900080 lw s0,128(a0)
174: 00021080 sll v0,v0,0x2
178: 246a003f addiu t2,v1,63
17c: 00441021 addu v0,v0,a0
180: 28660000 slti a2,v1,0
184: 8c450010 lw a1,16(v0)
188: 2469ffff addiu t1,v1,-1
18c: 0146180b movn v1,t2,a2
190: 8c870028 lw a3,40(a0)
194: 00052b42 srl a1,a1,0xd
198: 00031983 sra v1,v1,0x6
19c: 8c880084 lw t0,132(a0)
1a0: 34028004 li v0,0x8004
1a4: 0005283c dsll32 a1,a1,0x0
1a8: fe020000 sd v0,0(s0)
1ac: 00031c38 dsll v1,v1,0x10
1b0: 24020040 li v0,64
1b4: 24e7ffff addiu a3,a3,-1
1b8: 0005283e dsrl32 a1,a1,0x0
1bc: 00073c3c dsll32 a3,a3,0x10
1c0: 00084638 dsll t0,t0,0x18
1c4: fe020018 sd v0,24(s0)
1c8: 00a32825 or a1,a1,v1
1cc: 00094c38 dsll t1,t1,0x10
1d0: 2403000e li v1,14
1d4: 24020041 li v0,65
1d8: 00a82825 or a1,a1,t0
1dc: 01274825 or t1,t1,a3
1e0: fe030008 sd v1,8(s0)
1e4: 2403004c li v1,76
1e8: fe020038 sd v0,56(s0)
1ec: 2402004d li v0,77
1f0: fe030028 sd v1,40(s0)
1f4: fe090030 sd t1,48(s0)
1f8: fe020048 sd v0,72(s0)
1fc: fe090010 sd t1,16(s0)
200: fe050040 sd a1,64(s0)
204: 0c000000 jal 0 <gsKit_vram_alloc>
208: fe050020 sd a1,32(s0)
20c: 24040002 li a0,2
210: 0200282d move a1,s0
214: 0c000000 jal 0 <gsKit_vram_alloc>
218: 24060005 li a2,5
21c: dfb00000 ld s0,0(sp)
220: dfbf0010 ld ra,16(sp)
224: 03e00008 jr ra
228: 27bd0020 addiu sp,sp,32
22c: 00000000 nop
00000230 <gsKit_finish>:
230: 3c031200 lui v1,0x1200
234: 34631000 ori v1,v1,0x1000
238: dc620000 ld v0,0(v1)
23c: 0002107a dsrl v0,v0,0x1
240: 30420001 andi v0,v0,0x1
244: 00000000 nop
248: 1040fffb beqz v0,238 <gsKit_finish+0x8>
24c: 00000000 nop
250: 03e00008 jr ra
254: 00000000 nop
Posted: Sat Jul 21, 2007 7:29 pm
by Lukasz
Based on your assembly output, I've located the problem. The problem is with shifting of values, as I suspected, and it seems to be the very same problem I had with the Cygwin chains a long time ago.
You can see the bug yourself if you add this printf in gsKit_setactive
Code: Select all
*p_data++ = GIF_TAG( 4, 1, 0, 0, 0, 1 );
*p_data++ = GIF_AD;
printf("GIF_TAG = 0x%016lX\n", p_data[-2]);
My ps2toolchain built in Ubuntu prints this for each frame:
Where as the MinGW toolchain prints this once and hangs:
You will notice the missing '1' at the very first position of the value, this makes the GIF interpret the GIF packet incorrectly.
As I already mentioned I had this problem in Cygwin once, but later it just disappeared, which makes me suspect that the bug was in the tools I built the toolchain with and it later got fixed when I updated Cygwin and rebuilt the toolchains.
Unfortunately I don't have the knowledge to find and fix the problem in the GCC source, so my suggestion is to try to build the toolchains again, but this time choosing 'candidate' instead of 'current' when installing MinGW and see how this goes.
Posted: Sat Jul 21, 2007 9:22 pm
by chp
And if you don't want to spend all day just to see wether it works or not, the vista-toolchains I gave to Lukasz (so they are on the tutorial hp) are built with candidate and should give you a quick path to testing this.
Posted: Sun Jul 22, 2007 5:09 am
by ragnarok2040
I tested the vista-toolchains you provided chp, and they produce the same error.
GIF_TAG = 0x0000000000008004
GIF_TAG = 0x0000000000008004
I used the candidate versions of mingw last year to build my toolchain, and the versions haven't changed since then except for binutils, so whereever the problem is, it seems it still exists in the latest versions.
I'm gonna try the mingw toolkit from Ogre3D's site to compile the toolchain. If that doesn't work, I noticed there were places around the web that were providing updated mingw tools. There's a thread on the forums that lists the package versions they used to build a successful cygwin toolchain, so I'll use that for comparison.
Also, do you think the problem could be located with the patch.exe that msys provides?
Posted: Sun Jul 22, 2007 6:45 am
by Lukasz
The best I can do to help locate the problem is guess, as I have no real experience with gcc.
The best approach would probably be find where in the gcc source these 64 bit shifts are produced and go from there, or it could be a very long journey of guessing, possibly without success.
I was hoping the MinGW toolchains would make it easier to code PS2 in Windows, it doesn't seem to be the case. I'd recommend VMWare Player and installing Ubuntu inside it, this way you can still keep your Windows installation and experiment with Linux in a closed enviroment and avoid all the hassle with Cygwin and MinGW.