Expanded Windows Compile Guide

[cadbusca]

Well it turns out that the development SVN’s are not only dependent on the prereleased libogc but now are also dependent on custom mods to that code.

The following source code needs to be added to C:libogclibogclwp_heap.c
then recompile libogc and copy C:libogclib to C:devkitProlibogclib

My compile of SVN 528 now works.

//You need to add the next function in lwp_heap.c (libogc) to get debug info



u32 __lwp_heap_block_size(heap_cntrl *theheap,void *ptr)

{

heap_block *block;

u32 dsize,level;



_CPU_ISR_Disable(level);



block = __lwp_heap_usrblockat(ptr);

if(!__lwp_heap_blockin(theheap,block) || __lwp_heap_blockfree(block)) {

_CPU_ISR_Restore(level);

return 0;

}



dsize = __lwp_heap_blocksize(block);

_CPU_ISR_Restore(level);

return dsize;

}

[rodries]

…Or you could simply change the debug #define to 0 in the WiiMC code.

[cadbusca]

Anyone know where that is hidden?

[rodries]

The error was:

c:/devkitPro/msys/home/BadBoy/wiimc/source/utils/mem2_manager.c:176: undefined r

eference to `__lwp_heap_block_size'

So mem2_manager.c might be a good guess.

[cadbusca]

Seems to be the wrong place to look for #define debug, but if one were looking for #define DEBUG_MEM2_LEVEL it would be.

So assuming that is the target, it looks like this change would work. That’s a lot simpler than modifying libogc.

It would certainly be a better practice, and save a lot of wasted time, if the SVN’s were committed with such changes in place.

C:WIIMCsourceutilsmem2_manager.c

– //1: critical errors 2: detailed info
– #define DEBUG_MEM2_LEVEL 1 // to get info about used mem, it’s an approximation because of memory fragementation

+ // to get info about used mem, it’s an approximation because of memory fragmentation
+ //0: turn off debug 1: critical errors 2: detailed info
#define DEBUG_MEM2_LEVEL 0

[VoltManEXE]

I corrected the line you mentioned Tantric/jhb50, and the compiled dol/elf is created! Thanks for the info!

@jhb50: Are you working on a new Enhancement patch btw? 🙂

[cadbusca]

Apart from conflicts in input.cpp and menu.cpp which can all be resolved correctly by chosing “use this text box”, the R495 patch will merge correctly with SVN529, so there is no real need for an Enhancement Pack update at this time. The new features in Release IV will come when they are ready.

EDIT: This no longer appears to be the case. I have used this patch up to SVN508, but later SVN’s make more changes as noted in subsequent posts.

[rodries]

SVN is a developer scratchpad. There’s no guarantees it’s stable or even compiles. This is the way SVN works in any project – including mplayer itself. When a particular SVN revision comes along that we think is stable, we tag it as a version and then release it.

Right now that debug is enabled because we are, well, debugging.

[cadbusca]

That makes sense to me, and most SVN’s have compiled successfully with the previous environment. But it would be appreciated when requirements change if a short post could be made in “Development” so that the rest of us don’t chase our tails, and so you do not have your valuable time interrupted with all these what do I do now questions.

[twilbrand]

Freetype = http://sourceforge.net/projects/devkitpro/files/portlibs/freetype-2.3.11-ppc.tar.bz2/download/

That link doesn’t work anymore. It needs to be updated with the new link:
Freetype = http://sourceforge.net/projects/devkitpro/files/portlibs/freetype-2.4.2-ppc.tar.bz2/download

EDIT: on second thought, it looks like WiiMC doesn’t compile with the new version of freetype, it gives me the error:

So it looks like we’ll need either an alternate link to the old version of freetype, or some further instructions to make this new version work.

[Skanksta]

It’s still there, just in a different spot:

http://sourceforge.net/projects/devkitpro/files/portlibs/previous/freetype-2.3.11-ppc.tar.bz2/download

[Poe6661]

@jhb50 wrote:

Apart from conflicts in input.cpp and menu.cpp which can all be resolved correctly by chosing “use this text box”, the R495 patch will merge correctly with SVN529, so there is no real need for an Enhancement Pack update at this time. The new features in Release IV will come when they are ready.

I did a compile last night with SVN 531 and Enhancement Pack III. Like you mentioned, it was relatively straight forward to resolve the conflicts. One thing I did notice is there was a change to the interface GetExt. Instead of a function returning a value, it is now void:

void GetExt(char *file, char *ext);

So, there were a few places that I had to change. For example:

Where you see in the Enhancement Pack:

 char *ext = GetExt(file);

You will need to replace with:

char ext[6];

GetExt(file, ext);

Not a big deal, but thought I would mention it so you could include in any future Enhancement Packs.

[cadbusca]

Thanks, the “ext” change was made in SVN513in response to a bug I had identified. I thought I had posted a correction to my post, because I too have found problems in using the patch with 531. There is also a problem in 531 with the return of MPlayer detected errors like >1280 videos that also causes my “spec” reporting option to fail. I’ve advised the developers of that so hopefully it will be fixed in a subsequent SVN.

[cadbusca]

As of SVN529, the previous need to patch libogc introduced in SVN522 has been eliminated, and the new functions embedded in the WIIMC source code. Anyone who made this patch should remove it and recompile the libogc SVN and update devkitpro.

[Anonymous]

It would still be nice if the patch was updated for r133 (with all mentioned changes) so it could be applied cleanly 😉 I would be grateful, thanks!

[Author]

Posts