[stickman]

@Tantric wrote:

You’re quite right, these are just the support libraries and are included in libs/ for convenience. For some there has been slight modifications made to get them to compile properly for PowerPC.

Most of the time there’s no noticeable benefit updating them.

The most important support library, which you will likely see a benefit to keeping up to date, is libogc.

I understand now, thanks for your clarification. I was blindly using them without recompiling them for a while under my window built, until recently the addition of libmpg123, as well as small change in libntfs. But as you said, those changes are of cosmetic nature, not worth our effort to keep track of. So for libs, it’s most likely build once, use many times scenario.

In terms of libogc, I did notice, many useful loaders, such as usbloader gx, cfgloader, wiiflow, as well as wiixplorer all uses it, but when I built, I need to use their own libogc version, not the one for wiimc. I created separate versions for them, and symbolic them at different build times. I wish all of them share the same libogc version. It would be so much easier.

Puddles, thanks for all your help, I learned a lot from you.

[stickman]

jhb50,

I have a problem when playing onlinemedia by turning on the auto playing next video option. When I am trying to stop the playing one video, it will still trying to go to the next one, when I try to stop that, it will go on to the next, it’s annoying. I think the correct logic is when the user chooses to stop playing a video, it won’t AUTOMATICALLY go on to the next, until the user chooses to do so and if the user does not intervene, then it will go on AUTOMATICALLY. Does this sound reasonable? Thanks.

[stickman]

@puddles wrote:

Once the build completes there is some library that was built, buried down in the tree. This is what gets installed. Just determine a file that has to get built and use that to conditionally do the build.

For example:
dir1:
if [ ! -f libntfs/lib/libntfs.a ] ; then
cd libntfs && $(COMMAND1) ;
fi

Thanks puddles for your suggestions. Sorry for the delay in replying. One of my harddisk drive got corrupted, I am having a hard time trying to recover the data from. It includes many games and videos that I have extracted from my game and dvd collections. I did not have all of them backed up, it would be an ordeal to go through the extraction again, esp the movies, some of them I copied from some friends or relative’s dvds. So I was hoping I can recover the hd. The cause, probably by WiiXplorer’s ftp server. I was using it to copy some file from my PC to the External HD connected to Wii, then suddenly the HD contents got corrupted. 🙁

However, this may not be the desired solution. As we are not just interested in the existence of libntfs.a, but the dependency of the change of any of source files in the libntfs directory, any change at all, this includes all the .h and .c files.

Maybe a make depend inside the Makefile, and a Make config? Somehow, do a make depend, if there is any new change in the .h or .c files, then do a make config? Is this possible? Something like the following?

SOURCES: source/*.h source/*.c
dep: $(SOURCES)
makedepend -fdepend -Y -I../include $(SOURCES)
config:
./configure ….

[stickman]

FYI, in the build under Linux thread, puddles created a Makefile to compile for libs (it’s already been committed to svn since svn691) under linux. I have made some changes based on his recommendation, it’s able to build the libs under both win7 and ubuntu.Hope this is helpful for those who build regularly.

Reference:

1. http://www.wiimc.org/forum/viewtopic.php?f=5&t=906&start=16

[stickman]

puddles,

One more Q for you. Right now, when I go to libs, do a make, it will start to build for every library, does not matter whether there is any change or not. Is there a way to build only when there is a change? I guess one has to put in the right dependency. So what’s the best way of achieving this?

[stickman]

@puddles wrote:

@dynmosaic wrote:

For build under windows, the same Makefile won’t work, since there is no sudo -E command.

Yeah, I called the build steps dir1, dir2, dir3, etc. just to avoid the problem you discovered. I had thought of using d_pcre (for example) but thought it was too much typing.

If you’re interested in it building under windows also, better to just add some intelligence in the makefile itself, and use a single makefile.

Just have some conditional code like this in the Makefile:

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=sudo

endif



all:

@echo sudo command is $(SUDO_CMD)

Thanks puddles. A cross platform Makefile would be the best. I will test this.

Update:

On my Win7 installed with Cygwin, my uname is MINGW32_NT-6.1, but since I am only building under Windows and Linux, so an else would suffice, but if this Makefile is going to be made cross platform, maybe some other platform name should be included.

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=

endif



all:

@echo sudo command is $(SUDO_CMD)

I have included the new Makefile, tested working under both Win7 and Ubuntu 10.10. One more advantage, I no longer need to start a MingW windows, since my dos command line was setup with the correct path to my Cygwin installation. I think it’s because the change I made to your COMMAND3 with the addition of the –build for libmpg123. Anyway, here is my final Makefile.

ifeq ($(shell uname), Linux)

SUDO_CMD=sudo -E

else

SUDO_CMD=

endif

COMMAND1 = (make && $(SUDO_CMD) make install)

COMMAND2 = (CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc CXX=$(DEVKITPPC)/bin/powerpc-eabi-g++ ./configure --host=powerpc-eabi --build=powerpc-eabi-gnu --prefix="${DEVKITPRO}/portlibs/ppc" --libdir="${DEVKITPRO}/portlibs/ppc/lib" --disable-shared && 

make && $(SUDO_CMD) make install)

COMMAND3 = (CC=$(DEVKITPPC)/bin/powerpc-eabi-gcc ./configure --host=powerpc-eabi --build=powerpc-eabi-gnu --prefix="${DEVKITPRO}/portlibs/ppc" --libdir="${DEVKITPRO}/portlibs/ppc/lib" --enable-shared=no --enable-static=yes --with-cpu=ppc_nofpu --with-optimization=3 && 

cd src/libmpg123 && make && $(SUDO_CMD) make install)



all: dir1 dir2 dir3 dir4 dir5 dir6

dir1:

cd libntfs && $(COMMAND1)

dir2:

cd fribidi && $(COMMAND2)

dir3:

cd libexif && $(COMMAND2)

dir4:

cd libiconv && $(COMMAND2)

dir5:

cd pcre && $(COMMAND2)

dir6:

cd libmpg123 && $(COMMAND3)

I have also included the Makefile.gz for completeness.

[stickman]

Never mind, it won’t work by using the directory name. I guess by specifying the directory but not specifying the dependency, it simply check whether the directory exists or not.

For build under windows, the same Makefile won’t work, since there is no sudo -E command. I copied Makefile to Makefile.win, and removed all the occurances of ‘sudo -E’, everything works fine, I tested under MingW (ran as admin), except it choked on libmpg123. For that, I made the following change, I added the –build in COMMAND3, just as in COMMAND2, since the configure is complaining about “don’t use –host, but use –build” anyway, after the change, bingo, it worked.

So here is the Makefile.win.gz

[stickman]

@Tantric wrote:

Sounds good! I’ve committed this change.

Thanks Tantric for the quick commit, and thanks puddles for the fix. It works very well. I have thus deleted the sym link for features.h.

I really like puddles Makefile, one small improvement, just for readability, instead of using dir1, dir2, …, dir6, could we use the following instead?

all: libntfs fribidi libexif libiconv pcre libmpg123

libntfs:

cd libntfs && $(COMMAND1)

fribidi:

cd fribidi && $(COMMAND2)

libexif:

cd libexif && $(COMMAND2)

libiconv:

cd libiconv && $(COMMAND2)

pcre:

cd pcre && $(COMMAND2)

libmpg123:

cd libmpg123 && $(COMMAND3)

In this way, if a particular lib, for example, libntfs, was changed, I can simply do a make libntfs (instead of make dir1)

No biggie. I have included the changed Makefile.gz if you choose to use it.

[stickman]

Ataraxis,

Thanks for your help. However, if I get rid of the symbolic link that puddles provided, I could not get it to work. I have DEVKITPRO, DEVKITPPC exported correctly. I even update the path as you did. Although I don’t think WIILOAD is relevant here.

The following is my findings for features.h:

ubuntu:/$ sudo find -name features.h

./opt/devkitpro/devkitPPC/powerpc-eabi/include/sys/features.h

./usr/lib/syslinux/com32/include/syslinux/features.h

./usr/src/linux-headers-2.6.35-22/include/xen/features.h

./usr/src/linux-headers-2.6.35-22/include/xen/interface/features.h

./usr/include/features.h

./usr/include/wx-2.8/wx/features.h

./usr/include/c++/4.4/parallel/features.h

That’s strange.

[stickman]

@Ataraxis wrote:

all i did was changing the line ending and make it executable.
current svn does have this change.

dos2unix ./source/mplayer/version.sh
chmod +x ./source/mplayer/version.sh

dos2unix can be found in the package tofrodos

Thanks, Ataraxis, I am using the most recent svn. You did not have to do anything (like puddles did) to make the libs compile?

My problem was the same as what puddles had mentioned.

Puddles, after I applied your change wrt features.h, it compiles perfectly.

Now, for the same svn, I noticed that my windows build and ubuntu build is not the same size, is this normal? I will try them on my wii to see if there is any problem with the build. Will report back if there is anything unusual.

[stickman]

@Ataraxis wrote:

Just for the record, i have could compiled successfully under openSUSE 64bit and Ubuntu Maverick 32bit and the only things that I needed to change was the version.sh
Everything else worked fine.

Ataraxis, could you please share your change on version.sh with me?

puddles, I will try your fix for now to see what will bring. Will report back later if I have other problems. Thanks.

[stickman]

puddles,

Thanks for sharing.

I am trying to build using Ubuntu 10.10 64bits (as a vmware client). It’s very straight forward to follow the instructions and also by using your makefile.

However, I ran into problem when building the pcre lib. All other libs build fine.

This is the error I got:

checking for a BSD-compatible install... /usr/bin/install -c

checking build system type... Invalid configuration `x86_64-unknown-linux-': machine `x86_64-unknown-linux' not recognized

configure: error: /bin/bash ./config.sub x86_64-unknown-linux- failed

make: *** [dir5] Error 1

Any idea what I am doing wrong?

[stickman]

@hhansen wrote:

I don’t recall that specific discrepancy, but if you are using the EP, I would think using jhb50’s code is the way to go.

I am posting the EP with my updates for StartArea. Ultimately, jhb50’s EP V, when available, is the way to go. Hope this helps.

[attachment=0:qw1nag5t]EP IV SVN661.rar[/attachment:qw1nag5t]

Thanks hhansen for posting, what’s the best way to compare your patch, with mine?

[stickman]

@Tantric wrote:

This video now plays fine with WiiMC SVN, with the addition of some mplayer options to the code for larger videos like these.

Thanks a lot Tantric. I have tested with the svn672 and svn681(the newest as I am writing), it worked great.

Several things to notice though:

1. I took the settings out in metal.xml before, because it had problem recognizing my hdd. But wiimc refuse to start up in my recent svn builds, it came up with an error: AHBPROT is not enabled (or set). I searched around, found out in the HBC 1.0.7 document, that is required for AHBPROT. So I put it back in, it seems like my HDD is recognized again with this settings in.

2. In my settings, the Start Area somehow was set to be DVD, which came up with an error, I keep click the cancel button and it took a while before I can switch to other area.

Other than that, everything works great.

[stickman]

Thanks guys for pointing this out, that surely saves some efforts.

hhansen, this is what I did to find out all the possible (am I kidding? probably missed some already, jhb50, please help) places, since the additional global option StartArea was introduced in svn 607, I looked at the difference between svn 606 and svn 607 from here: http://code.google.com/p/wiimc/source/detail?r=607, then I made the corresponding changes and index shifts.

There is one question that I have missed in the past, there is a discrepancy in settings.cpp inside the function FixInvalidSettings().

In SVN607

if(WiiSettings.lockFolders != 1 && WiiSettings.lockFolders != 0)

WiiSettings.lockFolders = 0;

In EP IV for 1.1.0 R599

if(WiiSettings.lockFolders  4)

WiiSettings.lockFolders = 0;  //jhb50

Which one should we use?

jhb50, I knew that you are probably busy working on EP V, but if you don’t mind post the newest patch, that will be great, so I can keep learning.

Also, what’s planned for EP V?

[Author]

Posts