Print

[SmashManiac]

For a while I've experienced running homebrew Xbox apps with OpenXDK installed in Cygwin. However it was not practical for me because I needed to whether install Cygwin on my PC without being sure of that part of the 3Gb data to install, or having a 30-min ride to my university between each compilation and each execution. Bad, bad, bad...

Then I learned about MinGW, which is much better for me since it's much faster, far much smaller and no cross-compile Linux applications compatibility everywhere in the files.

I remembered that to use Cygwin I needed to change the beginning of the makefile to be able to detect paths correctly. For example, the beginning of the Samples_0.07 makefile is:

CODE

#
# update this variable to wherever you installed the OpenXDK libraries
#
PREFIX = /usr/local/openxdk

CC   = i386-pc-xbox-gcc
CPP  = i386-pc-xbox-g++
CXBE = cxbe

I needed to do the following:

CODE

#
# update this variable to wherever you installed the OpenXDK libraries
#
#PREFIX = /usr/local/openxdk
PREFIX = /cygdrive/c/openxdk

#CC   = i386-pc-xbox-gcc
#CPP  = i386-pc-xbox-g++
#CXBE = cxbe
CC   = gcc
CPP  = g++
CXBE = /cygdrive/c/openxdk/bin/cxbe

...then it worked correctly.

So I tried a similar thing for MSYS:

CODE

#
# update this variable to wherever you installed the OpenXDK libraries
#
#PREFIX = /usr/local/openxdk
PREFIX = /c/openxdk

#CC   = i386-pc-xbox-gcc
#CPP  = i386-pc-xbox-g++
#CXBE = cxbe
CC   = gcc
CPP  = g++
CXBE = /c/openxdk/bin/cxbe

I thought it would be enough when I encountered a surprising error message:

CODE

$ mingw32-make    
gcc -c comingSoon.c -c -g -std=gnu99 -ffreestanding -nostdlib -fno-builtin -fno-exceptions -mno-cygwin -march=i386 -DENABLE_XBOX -DDISABLE_CDROM   -I/c/openxdk/i386-pc-xbox/include -I/c/openxdk/include -I/c/openxdk/include/SDL
comingSoon.c:2:22: hal/xbox.h: No such file or directory
comingSoon.c:3:23: hal/video.h: No such file or directory
comingSoon.c:4:31: xboxkrnl/xboxkrnl.h: No such file or directory
comingSoon.c: In function `XBoxStartup':
comingSoon.c:8: warning: implicit declaration of function `XVideoGetFB'
comingSoon.c:31: warning: implicit declaration of function `XSleep'
comingSoon.c:32: warning: implicit declaration of function `XReboot'
C:\msys\1.0\mingw\bin\mingw32-make.exe: *** [comingSoon.o] Error 1

 (IMG:style_emoticons/default/blink.gif) WTF? (IMG:style_emoticons/default/blink.gif)

Obviously it can't find the files referenced in comingSoon.c... but that file can't be responsible for this! So I checked back the beginning of that file:

CODE

#include "comingSoon.h"
#include
#include
#include

I then did a search on which directory those 3 header files were. I easily found them in the C:\openxdk\include directory (with their correct hal and xboxkrnl directories). Which means that the -I parameter of MinGW's gcc.exe doesn't have the same behavior than Cygwin's gcc.exe. Is it the fault of MSYS? Is it the fault of MinGW's special gcc port? Is it something else I don't think of?

I have downloaded the "current" version of MinGW... but then I remembered there was a "candidate" version of GCC and binutils. So I downloaded them both, completely reinstalled MinGW, and tested it, without any more success.

Well I'm searching for a solution here. Of course I could change all the imports of every file, but that would be too long and too tedious. The only easy workaround I've guessed is to copy the C:\openxdk and the C:\openxdk\SDL directory directly in C:\msys\1.0\mingw\include directory... but that would be like crazy cramming those header files there like that!

Can somebody help me?

[d0wnlab]

as far as I remember, msys likes to play funny games with directories and the such.

If you open a MSYS shell, does the directory "/c" exist and point to the root of your C drive?  can you actually access the openxdk/include directory by cd-ing to /c/openxdk/include?

[SmashManiac]

That would be so lame! (IMG:style_emoticons/default/biggrin.gif)

CODE

User@PRIMARY ~
$ cd /c/openxdk/include

User@PRIMARY /c/openxdk/include
$ ls
SDL          SDL_ttf.h  jconfig.h   openxdk    usb       zlib.h
SDL_Mixer.h  hal        jmorecfg.h  png.h      xboxkrnl
SDL_image.h  include    jpeglib.h   pngconf.h  zconf.h

User@PRIMARY /c/openxdk/include
$ ls hal
audio.h  fileio.h  input.h  io.h  keyboard.h  mouse.h  pad.h  video.h  xbox.h

User@PRIMARY /c/openxdk/include
$ ls xboxkrnl
dbg.h  hal.h  kernel.h  nt.h  ps.h   types.h     xbox.h
ex.h   io.h   mm.h      ob.h  rtl.h  winerror.h  xboxkrnl.h

As you can see... yes, the C drive is mounted correctly in MSYS, and the openxdk directory is correctly shown. Though it doesn't appear directly even with "ls -al /", but I won't bother with that since Cygwin did the same thing by hiding its cygdrive directory with "ls -al /" too.

My current guess is there's a bug in whether MSYS or MinGW's GCC that renders useless the -I parameter of gcc.exe.

[d0wnlab]

If it's hidden by ls, the maybe gcc can't see that directory when it checks to see if that -I'd directory exists.

Try copying the openxdk include directory to somewhere else under the MSYS root (which is probably c:/msys/1.0 or something similiar) and reference it from there in the makefile.

*shooting in the dark*

[SmashManiac]

Shooting in the dark indeed! (IMG:style_emoticons/default/smile.gif)

Yes, MSYS is in C:\msys\1.0\ on my hard drive, so I installed both openxdk and Samples_0.07 directories with it:

CODE

User@PRIMARY /Samples_0.07
$ ls /
Samples_0.07  doc  home   mingw     msys.ico  uninstall
bin           etc  m.ico  msys.bat  openxdk

As you can see, now everything is directly shown under /. I then edited again my makefile:

CODE

#
# update this variable to wherever you installed the OpenXDK libraries
#
#PREFIX = /usr/local/openxdk
PREFIX = /openxdk

#CC   = i386-pc-xbox-gcc
#CPP  = i386-pc-xbox-g++
#CXBE = cxbe
CC   = gcc
CPP  = g++
CXBE = /openxdk/bin/cxbe

And it's time for a test...

CODE

$ mingw32-make
gcc -c comingSoon.c -c -g -std=gnu99 -ffreestanding -nostdlib -fno-builtin -fno-exceptions -mno-cygwin -march=i386 -DENABLE_XBOX -DDISABLE_CDROM   -I/openxdk/i386-pc-xbox/include -I/openxdk/include -I/openxdk/include/SDL
gcc -o comingSoon.exe comingSoon.o -L/openxdk/i386-pc-xbox/lib -L/openxdk/lib  -lSDL -lopenxdk -lhal -lc -lhal -lusb -lc -lxboxkrnl -nostdlib -Wl,--file-alignment,0x20 -Wl,--section-alignment,0x20  -shared -Wl,--entry,_WinMainCRTStartup  -Wl,--strip-all
/openxdk/bin/cxbe -TITLE:'comingSoon.exe' -DUMPINFO:"comingSoon.cxbe" -OUT:"comingSoon.xbe" comingSoon.exe > /dev/null
C:\msys\1.0\mingw\bin\mingw32-make.exe: *** [comingSoon.exe] Error 53

...with an error message popping in my face like: "cxbe.exe: cygwin1.dll not found"

But wait a minute... (IMG:style_emoticons/default/blink.gif) WHOA! It actually compiled the 1st file! I have a fresh comingSoon.exe and comingSoon.o in my directory! So it's MSYS's fault after all! I should shoot in the dark more often!!! (IMG:style_emoticons/default/ph34r.gif)

With the invalid directory thingy found, I'd bet that /dev/null isn't working either...

CODE

$ ls -al  /dev    
ls: /dev: No such file or directory

...seems to be confirmed: there's not even a /dev directory! So instead I'll completely change my makefile to output in a dummy file: dummy.txt. So I've changed every reference fo /dev/null with dummy.txt in the make file:
(no I won't post the whole thing just for that!)

New test... exact same error message. Maybe it's not /dev/null... let's try something simplier:

CODE

User@PRIMARY /Samples_0.07
$ echo doh
doh

User@PRIMARY /Samples_0.07
$ echo doh > /dev/null

User@PRIMARY /Samples_0.07
$ echo doh > dummy.txt

...and dummy.txt created with "doh". Well everything works there, so it's not again a bug in MSYS. Uh-oh... could it be that CXBE is a Linux program? I closed MSYS and directly tried to open CXBE.EXE from Windows:
"cxbe.exe: cygwin1.dll not found"

 (IMG:style_emoticons/default/grr.gif) ARRRRRGGGHHHH!!! (IMG:style_emoticons/default/grr.gif) It indeed is a Linux program! Crap! This is the lamest problem I couldn't ever thought: how to convert an EXE to an XBE in Windows! LAME LAME LAME! (Boy I sound creepy!) Well unless I ask Caustik to do it I think I think I'll need to find the source of CXBE (I think it's in openxdk's source) and recompile it for Windows... hope it won't be too tedious!

Hey wait a minute... now that I think of it, I thought I've already tried converting EXEs in XBEs directly in Windows and it was working. What's going on? Just to be sure, I just downloaded CXBE directly from the tools section of Xbox-Scene... guess what? This time it shows a help message in a DOS command shell! I go back to the OpenXDK's CXBE... still that missing cygwin1.dll...

So I tried replacing the OpenXDK's CXBE (after renaming it) to Xbox-Scene's CXBE and execute the same makefile again. Guess what: IT WORKED! ALL FILES COMPILED AND ARE CONVERTED!!! (IMG:style_emoticons/default/cool.gif) And when I compare file sizes between Cygwin's compilation and MinGW's compilation, they match! Although when I compare both files, they do have some small differences, I don't think it will be a problem (maybe not the same version of GCC?)

Well I'm seriously happy!  (IMG:style_emoticons/default/biggrin.gif) Thanks d0wnlab for your "shooting in the dark" suggestion, sometimes even those work! I'll confirm tommorow if indeed the XBE files works on my softmodded Xbox. (Now it's 01:07 AM for me and I'm in serious need of sleep!) I'll write a bug report to MinGW's team about that semi-hidden /c directory, and if my final test on my Xbox works I'll also ask OpenXDK's team to add the Windows version of CXBE in their package and update their notice on their website about MinGW.

Now I own you 2, d0wnlab! First Cygwin and then (unexpectedly) MinGW! Meanwhile, have more pop-corn!
 (IMG:style_emoticons/default/pop.gif)  (IMG:style_emoticons/default/pop.gif)  (IMG:style_emoticons/default/pop.gif)

[SmashManiac]

So I wanted to make my final test: test run on my softmodded Xbox. I was going to FTPd the files, but then it made me realize that I totally forgot to compile subdirectories of Samples_0.07. First sdlimage... change makefile, blablabla, try to compile, BANG:

CODE

$ mingw32-make
gcc -c sdlImageTest.c -c -g -std=gnu99 -ffreestanding -nostdlib -fno-builtin -fno-exceptions -mno-cygwin -march=i386 -DENABLE_XBOX -DDISABLE_CDROM  -I/openxdk/i386-pc-xbox/include -I/openxdk/include -I/openxdk/include/SDL
sdlImageTest.c:4:22: hal/xbox.h: No such file or directory
sdlImageTest.c:5:24: hal/fileio.h: No such file or directory
sdlImageTest.c:6:27: openxdk/debug.h: No such file or directory
sdlImageTest.c:7:17: SDL.h: No such file or directory
sdlImageTest.c:8:23: SDL_image.h: No such file or directory
sdlImageTest.c: In function `XBoxStartup':
sdlImageTest.c:12: error: `SDL_Surface' undeclared (first use in this function)
sdlImageTest.c:12: error: (Each undeclared identifier is reported only once
sdlImageTest.c:12: error: for each function it appears in.)
sdlImageTest.c:12: error: `screen' undeclared (first use in this function)
sdlImageTest.c:13: error: `picture' undeclared (first use in this function)
sdlImageTest.c:14: error: `picture2' undeclared (first use in this function)
sdlImageTest.c:15: error: `picture3' undeclared (first use in this function)
sdlImageTest.c:16: error: `SDL_Rect' undeclared (first use in this function)
sdlImageTest.c:16: error: syntax error before "pictureLocation"
sdlImageTest.c:18: warning: implicit declaration of function `SDL_Init'
sdlImageTest.c:18: error: `SDL_INIT_VIDEO' undeclared (first use in this function)
sdlImageTest.c:22: warning: implicit declaration of function `debugPrint'
sdlImageTest.c:23: warning: implicit declaration of function `IMG_Load'
sdlImageTest.c:26: warning: implicit declaration of function `XSleep'
sdlImageTest.c:38: error: `pictureLocation' undeclared (first use in this function)
sdlImageTest.c:42: warning: implicit declaration of function `SDL_SetVideoMode'
sdlImageTest.c:42: error: `SDL_DOUBLEBUF' undeclared (first use in this function)
sdlImageTest.c:42: error: `SDL_HWSURFACE' undeclared (first use in this function)
sdlImageTest.c:44: warning: implicit declaration of function `SDL_FillRect'
sdlImageTest.c:44: warning: implicit declaration of function `SDL_MapRGB'
sdlImageTest.c:45: warning: implicit declaration of function `SDL_BlitSurface'
sdlImageTest.c:52: warning: implicit declaration of function `SDL_Flip'
sdlImageTest.c:55: warning: implicit declaration of function `XReboot'
C:\msys\1.0\mingw\bin\mingw32-make.exe: *** [sdlImageTest.o] Error 1

Not again! It was my original error! Just to be sure, I try to recompile what I've successfully compiled yesterday:

CODE

User@PRIMARY /Samples_0.07
$ mingw32-make clean
rm -f *.o *.exe *.dll *.xbe *.cxbe

User@PRIMARY /Samples_0.07
$ mingw32-make      
gcc -c comingSoon.c -c -g -std=gnu99 -ffreestanding -nostdlib -fno-builtin -fno-exceptions -mno-cygwin -march=i386 -DENABLE_XBOX -DDISABLE_CDROM   -I/openxdk/i386-pc-xbox/include -I/openxdk/include -I/openxdk/include/SDL
comingSoon.c:2:22: hal/xbox.h: No such file or directory
comingSoon.c:3:23: hal/video.h: No such file or directory
comingSoon.c:4:31: xboxkrnl/xboxkrnl.h: No such file or directory
comingSoon.c: In function `XBoxStartup':
comingSoon.c:8: warning: implicit declaration of function `XVideoGetFB'
comingSoon.c:31: warning: implicit declaration of function `XSleep'
comingSoon.c:32: warning: implicit declaration of function `XReboot'
C:\msys\1.0\mingw\bin\mingw32-make.exe: *** [comingSoon.o] Error 1

NOOOOOOO!!! (IMG:style_emoticons/default/sad.gif)
I haven't touched any file! It worked yesterday! What the hell happened?!?!?!?

Now I'm totally desperate: what kind of bug did I found???

Think, think, think... now what's the thing to shoot right now in the dark?
...
...
...
Well I remember now that I've deleted the original C:\openxdk\ directory, so let's try putting it back and having 2 openxdk directories at the same time, like it was yesterday!

Guess what: it worked again! Whew! Shooting in the dark is fun! (IMG:style_emoticons/default/smile.gif)
So for fun I tried moving the openxdk directory out of MinGW's installation and let it running, to see if everything would work:

CODE

$ mingw32-make
gcc -c comingSoon.c -c -g -std=gnu99 -ffreestanding -nostdlib -fno-builtin -fno-exceptions -mno-cygwin -march=i386 -DENABLE_XBOX -DDISABLE_CDROM   -I/openxdk/i386-pc-xbox/include -I/openxdk/include -I/openxdk/include/SDL
gcc -o comingSoon.exe comingSoon.o -L/openxdk/i386-pc-xbox/lib -L/openxdk/lib  -lSDL -lopenxdk -lhal -lc -lhal -lusb -lc -lxboxkrnl -nostdlib -Wl,--file-alignment,0x20 -Wl,--section-alignment,0x20  -shared -Wl,--entry,_WinMainCRTStartup  -Wl,--strip-all
/openxdk/bin/w32-cxbe -TITLE:'comingSoon.exe' -DUMPINFO:"comingSoon.cxbe" -OUT:"comingSoon.xbe" comingSoon.exe > /dev/null
/usr/bin/sh: /openxdk/bin/w32-cxbe: No such file or directory
C:\msys\1.0\mingw\bin\mingw32-make.exe: *** [comingSoon.exe] Error 127

Well, it compiles, but cannot find CXBE.

So right now my theory is this (of course those bugs don't come from the original GCC):
- Though hidden from "ls -al /", MSYS can access to C drive at /c, but not GCC
- GCC -I parameter thinks the / directory is located in C:\ instead of the MSYS installation directory

So put back everything like it was, successful attempt to compile subdirectories, FTP'd to my Xbox, and try... let's say reboot.xbe...
...
...
Dang, it just freezes. Really sad after all of this trouble... (IMG:style_emoticons/default/sad.gif)

Well there's still something wrong. Maybe it's MinGW's bugs again. Maybe it's because I haven't installed back the "current" MinGW files and I am still with more bogus beta "candidate" files I installed while searching for that problem. I'll continue to search a solution to make my XBE works now...

Wow, I think I could have searched forever for this if I only moved the directory instead of copying it! (IMG:style_emoticons/default/dry.gif) Now this is what I think is a critical bug! I'll go to SourceForge and post my discoveries immediately. (aka the whole thread)

Meanwhile, if you have any suggestions, post it! And if you have MinGW, how about searching with me? (IMG:style_emoticons/default/happy.gif)

[d0wnlab]

Glad to see that we hit something (IMG:style_emoticons/default/smile.gif).  That is freaking dumb, whatever the reason is.  Glad you found a bit of a solution, though.

can you email me the XBE?  I'll take a look.  [email protected].

[SmashManiac]

*sending files*

Just tested with "current" version of MinGW, reboot.xbe still freezes. Actually, even though all 3 files have the same size, each one of them (cygwin, mingw current, mingw candidate) are different! Weird!

My bug report on SourceForge: https://sourceforge.net/tracker/index.php?f...435&atid=102435