Hacking How Can I Compile USB Loader GX

[D34DL1N3R]

changing line 57 of the makefile to

SVNREVÂÂÂÂÂÂÂÂ:=ÂÂÂÂ$(shell ./svnrev.sh)

wipes out the compiling errors.

Yes! Thank you!!!

 

[tj_cool]

thank you for adding it i didnt know about that.

I'm trying to make the readmii as complete as it can be.
And it seems to be working as there were very few questions the last time

But still, if someone sees a mistake or has a suggestion, please contact me

 

[Logan]

changing line 57 of the makefile to

SVNREVÂÂÂÂÂÂÂÂ:=ÂÂÂÂ$(shell ./svnrev.sh)

wipes out the compiling errors.

Thank you

 

[macmel]

@Snoozer

Thanks for the info, works for me also

 

[nicholasblock]

Anyone know why I get this error every time I try to compile?


CODE "make"
certs.dat
bin2s -a 32 /c/svnbuild/alo/data/certs.dat | powerpc-gekko-as -o certs.dat.o
echo "extern const u8" `(echo certs.dat | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`"_end[];" > `(echo certs.dat | tr . _)`.h
echo "extern const u8" `(echo certs.dat | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`"[];" >> `(echo certs.dat | tr . _)`.h
echo "extern const u32" `(echo certs.dat | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`_size";" >> `(echo certs.dat | tr . _)`.h
haxx.certs
bin2s -a 32 /c/svnbuild/alo/data/haxx.certs | powerpc-gekko-as -o haxx.certs.o
echo "extern const u8" `(echo haxx.certs | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`"_end[];" > `(echo haxx.certs | tr . _)`.h
echo "extern const u8" `(echo haxx.certs | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`"[];" >> `(echo haxx.certs | tr . _)`.h
echo "extern const u32" `(echo haxx.certs | sed -e 's/^\([0-9]\)/_\1/' | tr . _)`_size";" >> `(echo haxx.certs | tr . _)`.h
FreeTypeGX.cpp
In file included from c:/svnbuild/alo/source/FreeTypeGX.cpp:24:
c:/svnbuild/alo/source/FreeTypeGX.h:154:20: warning: gccore.h: No such file or directory
c:/svnbuild/alo/source/FreeTypeGX.h:155:22: warning: ft2build.h: No such file or directory
c:/svnbuild/alo/source/FreeTypeGX.h:156:10: error: #include expects "FILENAME" or
c:/svnbuild/alo/source/FreeTypeGX.h:157:10: error: #include expects "FILENAME" or
In file included from c:/svnbuild/alo/source/FreeTypeGX.cpp:25:
c:/svnbuild/alo/source/settings/cfg.h:4:21: warning: gctypes.h: No such file or directory
make[1]: *** [FreeTypeGX.o] Error 1
"make": *** [build] Error 2

> Process Exit Code: 2
> Time Taken: 00:02

 

[macmel]

Anyone know why I get this error every time I try to compile?

Whenever I get an error from Compiling, what I do is delete the files inside my gx SVN Update folder then run SVN Update to get fresh files and compile which usually bears good results.

Try that and see if it works for you too

 

[giantpune]

dont confuse "error" with "warning". there is a difference. error usually will not compile. warning usually will compile, but it just makes some pretty purple text while it does. we can get rid of every single compile warning we have with changing 1 figure in the makefile but for the sake of making the dol smaller, it is still there.

 

[emupaul]

a good #pragma warning( disable : 4172 ) would work... well the four digit number will need to be changed to the warning codes the compiler is whining about while its trying to compile and build usbloader. However it's like kind of shoving crap under a rug, it will come back later and prolly make you sick...happens to be

the pragma warning in this case is for returning address of local variable or temporary. some libs have built in predefined macros that will silent warnings too, especially notorious for that is the boost libs, so i like suppressing all the warnings about templates and crap if i'm building a c++ application. Strict C is a whole different world.

also to the user who couldn't compile. Your directories are not being found... and stuff from a header that is there is missing something... sounds like a some white-space issues or outdated old library that needs to be updated and or a library you installed is to new that usbloader revision depends on fails because the orginal file usbloader was looking for has changed so much its not recognized and would require your code that depends on such lib to be updated such was what is being done every new build.

Get your development environment set up right and rebuild again. You may want to know what environment variables are too, cause those also may be broken.

These are svn builds and are considered bleeding edge, it may not work all the time. Take the advice of other members and just start over with a fresh checkout and then try again. Maybe a couple days between code updates will yield better results for you... but if you are consistently failing to build the project then you really should overhaul your build environment because something is jacked up and it could be as simple as one corrupt header (h) or lib (o or lib), if you still cant get it then you lack some understanding somewhere in between and should really read book on programming.

 

[nicholasblock]

I tried to delete the files and update but no luck. I am using devkitpro 1.5 and the updated libogc from the usbgx googlecode site. I have compiled this before so I dont understand. I am really interested in programing and just started school for it so maybe ill do some more reading. Thank you everyone for the help

 

[antiaverage]

http://usbloader-gui.googlecode.com/files/...-08-07-2009.zip

^ is gone

Can someone re-up or possibly upload their working libogc folder?

Edit:

There is now this file in the downloads
http://usbloader-gui.googlecode.com/files/...-02-08-2009.zip

Should the link in the first post be changed?

Edit:

Still getting the following error

/opt/devkitpro/libogc/lib/wii/libogc.a(ipc.o): In function `__ios_ioctlvformat_parse':
ipc.c:(.text.__ios_ioctlvformat_parse+0x174): undefined reference to `__ctype_ptr__'
/opt/devkitpro/devkitPPC/lib/gcc/powerpc-gekko/4.2.4/../../../../powerpc-gekko/bin/ld: /opt/devkitpro/libogc/lib/wii/libogc.a(ipc.o)(.text.__ios_ioctlvformat_parse+0x174): unresolvable R_PPC_EMB_SDA21 relocation against symbol `__ctype_ptr__'
ipc.c:(.text.__ios_ioctlvformat_parse+0x4e8): undefined reference to `__ctype_ptr__'
/opt/devkitpro/devkitPPC/lib/gcc/powerpc-gekko/4.2.4/../../../../powerpc-gekko/bin/ld: /opt/devkitpro/libogc/lib/wii/libogc.a(ipc.o)(.text.__ios_ioctlvformat_parse+0x4e8): unresolvable R_PPC_EMB_SDA21 relocation against symbol `__ctype_ptr__'
/opt/devkitpro/devkitPPC/lib/gcc/powerpc-gekko/4.2.4/../../../../powerpc-gekko/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [/Users/sayret/Documents/Code/usbloader-gx/boot.elf] Error 1
make: *** [build] Error 2

Any thoughts?

Edit:

Yeah, so, lesson learned, forget the zipped pre-compile.

Just checkout:
https://devkitpro.svn.sourceforge.net/svnro...ro/trunk/libfat
https://devkitpro.svn.sourceforge.net/svnro...ro/trunk/libogc

and make and make install each yourself.

I am now compiling usbloader-gx just fine.

Wee

If anyone needs help getting this to compile on a Mac, just give me a shout. I've worked out the entire process and now have fixed usbloader-gx to once again be able to download covers.

Edit:

Here's the compiled version of r713 I made which has working cover/discart downloads
usbloader-gx r713 with working cover/discart downloads

 

[AceLighting]

Im trying to compile libogc on windows vista but im getting this error :
with msys or cmd i got to the directory then i done make

C:\libogc>make
make[1]: Entering directory `/c/libogc/wii'
make[1]: *** No rule to make target `console.o', needed by `/wii/libogc.a'. Sto
p.
make[1]: Leaving directory `/c/libogc/wii'
make: *** [wii] Error 2

C:\libogc>

 

[WiiPower]

Im trying to compile libogc on windows vista but im getting this error :
with msys or cmd i got to the directory then i done make

C:\libogc>make
make[1]: Entering directory `/c/libogc/wii'
make[1]: *** No rule to make target `console.o', needed by `/wii/libogc.a'. Sto
p.
make[1]: Leaving directory `/c/libogc/wii'
make: *** [wii] Error 2

C:\libogc>

Do you have DevKitPro installed? And if you _just_ did, do a reboot.

 

[AceLighting]

Im trying to compile libogc on windows vista but im getting this error :
with msys or cmd i got to the directory then i done make

C:\libogc>make
make[1]: Entering directory `/c/libogc/wii'
make[1]: *** No rule to make target `console.o', needed by `/wii/libogc.a'. Sto
p.
make[1]: Leaving directory `/c/libogc/wii'
make: *** [wii] Error 2

C:\libogc>

Do you have DevKitPro installed? And if you _just_ did, do a reboot.

Yeah i have devkitpro installed. i dont know why im getting this error

Edit : im on windows vista

 

[lo9ik]

This stuff is pretty old, but it helped me in doing what I needed to do which I am so thankfull for, which is why I'm sharing this data. This instructions are for Windows and these instructions are for someone that has a little programming background:

1) The latest code for Usb Loader GX is now on sourceforge (I was trying to post the link but the page won't let me): sourceforge.net/p/usbloadergx/code/HEAD/tree/trunk/ and you will also need to grab their devkit libraries here: sourceforge.net/projects/usbloadergx/files/Libraries/

2) Download DevKitPro (a IDE made to help people easily get into game programming), it says it will come with the Programmer's Notepad, but it doesn't, or at least it didn't install for me. There was some helpfull "getting started" notes at DevKitPro's website for manually setting up Programmer's Notepad, but it isn't really necessay since you can do everything from the command line.

3) Launch MSys2 from Windows | Start | DevKitPro | MSys2; then CD to your working directory (where you extracted the files for usb loader gx). Many, many times I read that you should not have spaces or special characters in your path.

4) In MSys2, type "make clean" then "make" OR if you have the Programmer's Notepad all setup, just double click on the .pnproj file and run clean and make from the UI. You will get an error in building for several reasons, but the big one is because Usb Loader GX uses custom DevKitPro libraries.

5) Navigate to c:\devkitpro (or whatever your install directory was) and rename devKitPPC and libogc, I named them like libogc_orig for example. We need to replace these folders with the ones we downloaded from usbloadergx, but we want to keep the original ones so we can build projects outside of usb loader gx if needed.

5b) Copy the extracted portlibs we downloaded from usb loader's site to your devKitPPC's install folder in a subfolder named portlibs.

6) For me, the libwiidrc.a file was missing from the usbloadergx's libogc folder, so I copied it from another project (wiiflow actually) which is a little sloppy on my part, but I was just trying to get it to compile.

7) That was it and everything compiled. Just make sure you do a "make clean" and then "make" when you fix a problem.

8) Once I had that working, I tested it out. Then I went over and grabbed the code for DevKitPro, modified the classic.c file as described here: *updated* gbatemp.net/threads/latest-emulator-and-libogc-with-3rd-party-classic-controller.217245/page-35#post-4989135 * (which is commenting out the wiiuse_read_data line with the 0xFF value is found), changed the devKitPPC and libogc folders back to the originals, and compiled the newer version.

9) I then took the libwiiuse.a that was compiled, copied it into libogc folder that is used to compile usbloader, put the devKitPPC folder back so usbloader would compile and built.

I have all of these files here (the built usb loader, the modified classic.c file, and the build libwiiuse.a library): h.ttps://ufile.io/jeren which is good for 30 days starting today.

I have also attached the files to a ticket over here: h.ttps://sourceforge.net/p/usbloadergx/issues/2363/

 

[Cyan]

it works fine with msys2? I didn't try yet.
I'm still using an old installation of devkitpro installer, with old libraries, so I didn't know you could install current tools and mix them with old libraries.

for the missing .a libraries, you need to compile them (they are in /branches/libs/) and type "make install", or copy the .h and .a into libogc. on next revisions I will include the .h and .a directly into the loader's sources so you don't need to compile and merge into libogc manually.

What is this classic.h modification used for? I might have miss it in this thread. is it something needed to fix third parties classic controllers? it's included in newer libwiiuse?
I don't have third party controllers to test.

thank you for sharing and sorry to still haven't updated the sources to compile on newest toolchains. but it seems msys2 is working so it's good to know.


Additional information you might find useful:

Spoiler: not for newbie, please don't mess with your installation! OR don't complain to wintermute, this is NOT how you should use devkitpro at all

If you want to keep compiling different projects using different libraries, portlibs and libogc versions, you could do it like this :

keep your latest devkitppc official toolchains (devkitppc, libogc and portlibs).

Create a new folder in your devkitpro folder, for example "usbgx" for USBLoaderGX.
inside, copy the devkitppc, portlib and libogc folder you want to use.
usbgx/devkitppc_r29-1/ <-- last tested version, no idea if it compiles fine with r33 yet.
usbgx/libogc/ <-- provided package for the loader
usbgx/portlibs/ <-- provided package for the loader

in that ppc folder, edit :
- the wii_rules file, you'll find libogc path in it, edit the 2 "export" lines to point to /usbgx/ subfolder

export	LIBOGC_INC	:=	$(DEVKITPRO)/usbgx/libogc/include
export	LIBOGC_LIB	:=	$(DEVKITPRO)/usbgx/libogc/lib/wii

- the base_rules file, you'll find the portlib path in it, edit the "export PORTLIBS :" to point to /usbgx/ subfolder

export PORTLIBS	:=	$(DEVKITPRO)/usbgx/portlibs/ppc

Now you have a "sandboxed" devkitppc folder for one specific homebrew with its own libraries, not conflicting with default and latest version of the toolchain for other homebrew.

Before compiling, set the environment variable of the devkitppc you want to use, in msys or windows command line tool (it'll set it temporarily for this command line window only)

Note: I'm using windows command line tool, I never launched msys manually, so I don't know if the "set" command works in msys. if not, just make a .bat file with this inside:

SET DEVKITPPC=/c/devkitPro/usbgx/devkitPPC_r29-1
clean
make

Edit :
If you plan to compile USBLoaderGX, you might also want to install SlikSVN, as it'll be used to auto-increment the revision of the loader at compile time.
if you don't auto-increment, you have to edit source/svnrev.h file manually, or the loader won't be able to save your settings.
you'll also won't be able to add new resources (png for themes for example).

 

[lo9ik]

it works fine with msys2? I didn't try yet.
I'm still using an old installation of devkitpro installer, with old libraries, so I didn't know you could install current tools and mix them with old libraries.

for the missing .a libraries, you need to compile them (they are in /branches/libs/) and type "make install", or copy the .h and .a into libogc. on next revisions I will include the .h and .a directly into the loader's sources so you don't need to compile and merge into libogc manually.

What is this classic.h modification used for? I might have miss it in this thread. is it something needed to fix third parties classic controllers? it's included in newer libwiiuse?
I don't have third party controllers to test.

thank you for sharing and sorry to still haven't updated the sources to compile on newest toolchains. but it seems msys2 is working so it's good to know.


Additional information you might find useful:

Spoiler: not for newbie, please don't mess with your installation! OR don't complain to wintermute, this is NOT how you should use devkitpro at all

If you want to keep compiling different projects using different libraries, portlibs and libogc versions, you could do it like this :

keep your official and latest devkitppc, and other folder's names as "devkitppc" "libogc" and "portlibs".

Create a new folder in your devkitpro folder, for example "usbgx" for USBLoaderGX.
inside, copy the devkitppc, portlib and libogc folder you want to use.
usbgx/devkitppc_r29-1/
usbgx/libogc/
usbgx/portlibs/

in that ppc folder, edit :
- the wii_rules file, you'll find libogc path in it, edit the 2 "export" lines to point to /usbgx/ subfolder

export    LIBOGC_INC    :=    $(DEVKITPRO)/usbgx/libogc/include
export    LIBOGC_LIB    :=    $(DEVKITPRO)/usbgx/libogc/lib/wii

- the base_rules file, you'll find the portlib path in it, edit the "export PORTLIBS :" to point to /usbgx/ subfolder

export PORTLIBS    :=    $(DEVKITPRO)/usbgx/portlibs/ppc

Now you have a "sandboxed" devkitppc folder for one specific homebrew with its own libraries, not conflicting with default and latest version of the toolchain for other homebrew.

Before compiling, set the environment variable of the devkitppc you want to use, in msys or windows command line tool (it'll set it temporarily for this command line window only)

Note: I'm using windows command line tool, I never launched msys manually, so I don't know if the "set" command works in msys. if not, just make a .bat file with this inside:

SET DEVKITPPC=/c/devkitPro/usbgx/devkitPPC_r29-1
clean
make

Yes, it works with Msys2, or at least as much as I tested it. I didn't know any better

My bad, the classic.c post was here: gbatemp.net/threads/latest-emulator-and-libogc-with-3rd-party-classic-controller.217245/page-35#post-4989135 I also have it in that zip file I attached.

I commented out the code as seen below in the wiiuse\classic.c file - this isn't a great "fix" but it worked for me; if there was a way to do a try/catch statement that would be much better but my limited knowledge prevents me from making this a real win.

        if (data[offset] == 0xFF) {


            if (data[offset + 16] == 0xFF) {
                /* get the calibration data again - removed as mentioned in gbatemp.net/threads/latest-emulator-and-libogc-with-3rd-party-classic-controller.217245/page-35#post-4989135
                WIIUSE_DEBUG("Classic controller handshake appears invalid, trying again.");
                wiiuse_read_data(wm, data, WM_EXP_MEM_CALIBR, EXP_HANDSHAKE_LEN, wiiuse_handshake_expansion);
                */
            } else
                offset += 16;
        }

 

[Cyan]

ah thank you for the link.
commenting out that part might break other legit controllers calibration?
did you try Jaobeian solution adding a return 0; ?

there is a way to try/catch, but it would be cleaner with a proper check of the read data or detect first/third parties controller and act accordingly.
I suppose other developers spent more time on that issue so if there were a better way it would already be included in updated libogc versions.

I'll see if I can include that modified libwiiuse in the libogc used by the loader.
thank you for the files