I just set up devkitPPC, plus portlibs, libogc, SDL-Wii etc. and am trying to get started on a Wii port of an open-source SDL-based game. I'm currently at the point where it compiles, but I'm getting linker errors that I don't understand:

Any idea what I might be doing wrong, particularly with the "undefined reference" errors? It's almost like the libraries I'm trying to link have additional dependencies that I need to also link, but I wouldn't know what.

You've installed the toolchain incorrectly - libogc.a should not be in /opt/devkitpro/libogc/lib/. The release tarball has cube and wii folders in there which both contain their own version of libogc.a.I haven't looked recently but I'm pretty sure that the SDL install instructions also require wii and cube specific versions installed in those folders.

From the output you show it looks like you used configure to get things started so you'll need to clean that or ideally start again from a fresh copy. make distclean may work, depending on the project. You need a few more options than are shown for the portlibs when building actual applications

The -mrvl option builds code for wii and, when supplied at link time, selects the appropriate linkscript and crt0. For gamecube code you need to change this to -mogc and use lib/cube instead of lib/wii

-lwiikeyboard shouid be before -logc in the link line - order of libraries is important.

You've installed the toolchain incorrectly - libogc.a should not be in /opt/devkitpro/libogc/lib/. The release tarball has cube and wii folders in there which both contain their own version of libogc.a.I haven't looked recently but I'm pretty sure that the SDL install instructions also require wii and cube specific versions installed in those folders.

They actually are installed to those folders (I was meticulous in following the wiibrew.org instructions and the additional ones that it links to), but I made symbolic links in lib/ to the libraries in lib/wii specifically because configure was not smart enough to figure out the special directory structure (and I was not smart enough to figure out a better way to work around that, plus I have absolutely zero interest in Gamecube development).

Quote:

The -mrvl option builds code for wii and, when supplied at link time, selects the appropriate linkscript and crt0. For gamecube code you need to change this to -mogc and use lib/cube instead of lib/wii

Aha! That's almost definitely what I was missing. I'll give that a shot.

Quote:

-lwiikeyboard shouid be before -logc in the link line - order of libraries is important.

I guess the SDL-Wii page on the wiibrew.org wiki is in error then: http://wiibrew.org/wiki/SDL_Wii#Usage (as are most of the SDL-Wii sub-pages on there, as many list similar library orders).

I intend to remove keyboard support once I iron out these toolchain issues, as I think the game is ideally suited to a Wiimote+Nunchuk control style.

You've installed the toolchain incorrectly - libogc.a should not be in /opt/devkitpro/libogc/lib/. The release tarball has cube and wii folders in there which both contain their own version of libogc.a.I haven't looked recently but I'm pretty sure that the SDL install instructions also require wii and cube specific versions installed in those folders.

They actually are installed to those folders (I was meticulous in following the wiibrew.org instructions and the additional ones that it links to), but I made symbolic links in lib/ to the libraries in lib/wii specifically because configure was not smart enough to figure out the special directory structure (and I was not smart enough to figure out a better way to work around that, plus I have absolutely zero interest in Gamecube development).

You'll be better off removing those symlinks - sadly bodges like that have a habit of spreading around the community & need to be stomped on otherwise we end up with projects that only build on the machine they were originally created on. Adding -L$DEVKITPRO/libogc/lib/wii to LDFLAGS during configure is the proper way to do it.

Don't give up just yet, you're very, very close and, most impressively, you've actually used configure instead of the usual mess people create by bodging Makefiles.

The multiple definition of `main' is caused by the project you're porting expecting to have main redefined to SDL_main on the fly, I believe this is usually done by sdl-config outputting -Dmain=SDL_main for --cflags.

It looks like there's a collision for the color_table symbol which can be resolved by either renaming it in the project or I can rename it in libogc, it should probably be internal anyway. Actually I've just rolled a release which makes that array static, it's only used by the console stuff anyway.

The code that uses getlogin needs to be rewritten - obviously the wii has no login shell so you can probably just ifdef it out. devkitPPC will define __wii__ when -mrvl is used and __gamecube__ for -mogc. Ideally you should probably check for both and leave things open - even if you have no interest in gamecube someone else probably will.

Great work doing this port the right way using the existing autotools setup, I look forward to seeing whatever it is

You've installed the toolchain incorrectly - libogc.a should not be in /opt/devkitpro/libogc/lib/. The release tarball has cube and wii folders in there which both contain their own version of libogc.a.I haven't looked recently but I'm pretty sure that the SDL install instructions also require wii and cube specific versions installed in those folders.

They actually are installed to those folders (I was meticulous in following the wiibrew.org instructions and the additional ones that it links to), but I made symbolic links in lib/ to the libraries in lib/wii specifically because configure was not smart enough to figure out the special directory structure (and I was not smart enough to figure out a better way to work around that, plus I have absolutely zero interest in Gamecube development).

You'll be better off removing those symlinks - sadly bodges like that have a habit of spreading around the community & need to be stomped on otherwise we end up with projects that only build on the machine they were originally created on. Adding -L$DEVKITPRO/libogc/lib/wii to LDFLAGS during configure is the proper way to do it.

Already took those suggestions to heart from your previous reply, including blowing away the symlinks

Quote:

Don't give up just yet, you're very, very close and, most impressively, you've actually used configure instead of the usual mess people create by bodging Makefiles.

The source for this project actually came with only autoconf-level stuff, so I had to generate even the configure script before I could then have that generate a set of Makefiles. I didn't expect to get this far either, especially after setting the anti-configure attitude of the SDL-Wii team.

Speaking of which, I also hit an incompatibility between devkitPPC and SDL-Wii that was dismissed out-of-hand by the SDL-Wii team because they spotted my use of configure: http://code.google.com/p/sdl-wii/issues/detail?id=43 . I resolved this by commenting out SDL-Wii's definition of uintptr_t. Why doesn't SDL-Wii include the toolchain's definitions instead of defining its own? Seems improper to me.

Quote:

The multiple definition of `main' is caused by the project you're porting expecting to have main redefined to SDL_main on the fly, I believe this is usually done by sdl-config outputting -Dmain=SDL_main for --cflags.

I tried hacking -Dmain=SDL_main into the Makefiles last night, but it didn't help. I don't remember if I did a make clean first, or if I went straight to the linker stage; I'll have to try again tonight.

Quote:

It looks like there's a collision for the color_table symbol which can be resolved by either renaming it in the project or I can rename it in libogc, it should probably be internal anyway. Actually I've just rolled a release which makes that array static, it's only used by the console stuff anyway.

Thanks. If I can get past the SDL_main issue then I'll update libogc and let you know how it goes.

Quote:

The code that uses getlogin needs to be rewritten - obviously the wii has no login shell so you can probably just ifdef it out. devkitPPC will define __wii__ when -mrvl is used and __gamecube__ for -mogc. Ideally you should probably check for both and leave things open - even if you have no interest in gamecube someone else probably will.

Will do, thanks.

That reminds me that I also had to disable the network code in this game to eliminate some other compiling issues, but they allowed me to do that via an argument to configure. I think they're still working on that part of the code, so the problems may be on their end rather than an issue with the toolchain.

Quote:

Great work doing this port the right way using the existing autotools setup, I look forward to seeing whatever it is

Thanks for the encouragement. It's good to know that hatred of autotools isn't a community-wide thing. I am still struggling a bit with configure, as it seems to like to mysteriously tack extra -lSDL_Mixer tags onto the end of LIBS and such, but I've managed to get by with minor post-configure Makefile massaging so far.

I did notice that game.cpp (which has main() defined) was not doing #include <SDL.h>, so I added that - but no dice. Tried adding #include <SDL_main.h> as well (whatever that does), but that didn't help either.

I checked the signature of main(), and it looks reasonable:

Code:

int main(int argc, char *argv[])

After some more Google-fu, I tried adding extern "C" out of desperation:

Code:

extern "C" int main(int argc, char *argv[])

...and it worked! WTF? That's a ridiculous and nonsensical hoop to have to jump through, and I don't understand why it is necessary.

Time to update my copy of libogc to pick up your color_table fix, and then see where that leads me. I suspect I will be inserting lots of "#if (defined(__wii__) || defined(__gamecube__))" statements around lots of Wii-specific code

There's a note in the SDL headers that you need to extern "C" your main to get it to work with C++, it's basically because it supplies it's own main that does some setup before running the user's main.

I've been attempting to get the SDL wii guys to switch to using the autotools setup for years without much success. Sadly it seems to scare people which is a bit of a shame considering how well it works and how much work I put into the toolchain setup so it's possible to do with devkitPPC & devkitARM. I'm still not 100% sure how to deal with tools that are meant for the build system when you're cross compiling, often setting --host builds them for the target system instead which might lead to some problems with what you're porting.

You did inspire me to have a look at using configure && make to build wii SDL though, I've managed to get it to build & install but I'm not yet sure if I've managed to get all the changes that were done for wii. I'm trying to figure out how to get the configure for the tests to ignore build system libraries atm. Right now it's decided to pick up openGL which is a bit annoying.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum