!!!SOLVED!!! LibMii Mod - GRR_TextImg Reference Undefined

I am taking the libMii sample code (available on Wiibrew.org) that mdbrim has posted and I am trying to turn it into a nice library. I like mdbrim's selection menu so I kept all that and just wrapped it into a function that one can call. I also added a function that draws the selected Mii so the main program does not need to be bothered with any of the library variables (such as img_mii).

I have written a very simple program to test the library but it won't compile. When I try to compile is complains about Undefined Reference to my texture image (tile set) arrays.



I know the associated array files are loading because if I change the path or name of these files (.h and .c) then the compiler complains about the missing file instead. I have verified that the variable name matches and it does. I tried moving the location of the images and even inclduign them from the main program instead of the library but I always get the same error.

Does anyone have some ideas what is the problem?

The source code for the program can be downloaded at:

[www.mediafire.com]

There are two three ZIP files. One is the files that are placed in libogc directory (include and lib) for the libMii library to work and also includes the Mii header file. The second is the GRRLIB_miis.h header file that I added to GRRLIB to implement the Mii functions. The second third is the sample program which is trying to use this modified library.



Edited 4 time(s). Last edit at 04/12/2010 02:07PM by LordAshes.

Are you trying to reference a static variable from another file? That simply doesn't work. There's no need to declare a global variable static unless you anticipate name collisions at link time AND you only reference the variable from the file in which it's defined. If you're compiling in C++ you should be using namespaces to prevent name collisions.

In short this is a no-no:
.h:
extern Foo bar;
.c:
static Foo bar;

Remove the static; you can't see anything when the picture has too much static:
.h:
extern Foo bar;
.c:
Foo bar;

Quote
calvinss4
Remove the static; you can't see anything when the picture has too much static:

I removed all the static (changed them to regular variables) and fixed a search and replace bug...but the problem persists.

I still get the Undefined Reference error. The line of code that the compiler points to is the assignment lines indicated in read in the original post. The other interesting thing is that each line seems to trip an error message from the compiler twice.

I have updated the downloadable source code to reflect this change.



Edited 1 time(s). Last edit at 04/11/2010 08:52AM by LordAshes.

#include "miis\mii_heads.h"

int main()
{
  img_heads = GRRLIB_LoadTexture(mii_heads);
}

Let's start simple, referencing the example above. You're getting a linker error; main.c compiles just fine, which means it can "see" mii_heads (i.e. mii_heads is declared somewhere), but when linking the dependent object files into main.o, it can't find an object file that provides a definition for mii_heads.

So I'm guessing you have a declaration in mii_heads.h:
extern SomeType mii_heads;

Well, where do actually define it? Do you have a corresponding mii_heads.c with the following?
SomeType mii_heads;

Your build directory must contain a mii_heads.o (which contains the definition for the variable mii_heads). If you don't have a mii_heads.c, then I will assume mii_heads.o is generated directly from some data source (like an image file), in which case you must make sure your makefile is set up properly.

Finally, if you are sure you have coded everything correctly and are still getting linker errors, then it's possible there was a dependency error and the linker is referencing a stale object file; in that case do a "clean all" followed by a "make all".

Well your approach is not right... the best place to put the mii rendering functions is Grrlib which I think is the main intention by mdbrim hence the naming of the functions starting with Grrlib...

So, instead of trying to make it another library you can just create another file under Grrlib and add the functionality there... So it becomes part of Grrlib...

You "libogc addition.zip" is not quite right. It contains both parts that relates to include & lib folder... .h files goes to include and the rest of the code actually become part of the lib... (take a look at libogc folder, you won't find any c files there)

So it's better you try to integrate it with Grrlib... It already has a makefile to build as a library...

Yeah dude, if those header files reference a variable that's defined in a library, then you have to set up your makefile to link with that library. You can think of a library file as a pre-compiled object file.

Quote
calvinss4
So I'm guessing you have a declaration in mii_heads.h:
extern SomeType mii_heads;

Well, where do actually define it? Do you have a corresponding mii_heads.c with the following?
SomeType mii_heads;

Your build directory must contain a mii_heads.o (which contains the definition for the variable mii_heads). If you don't have a mii_heads.c, then I will assume mii_heads.o is generated directly from some data source (like an image file), in which case you must make sure your makefile is set up properly.

I have the corresponding c files. They are currently in the same directory as the h files (i.e. the "miis" sub-directory).
I wonder if my problem is that the "miis" directory needs to be added somewhere in my MakeFile.

Quote
calvinss4
Finally, if you are sure you have coded everything correctly and are still getting linker errors, then it's possible there was a dependency error and the linker is referencing a stale object file; in that case do a "clean all" followed by a "make all".

I believe I have all the necessary files. The bulk of the code was download from Wiibrew and I have done some work with GRRLIB before. The only significant change that I did was to change the location of these image files...from a sub-directory off the project to a sub-directory off the library. I was hoping, in this way, to eliminate the need for the user to have to include all these images in his/her project.

I will try the "clean all" and "make all" approach to see if that solves my problem. Thanks for the advice.

Quote
I.R.on
Well your approach is not right... the best place to put the mii rendering functions is Grrlib which I think is the main intention by mdbrim hence the naming of the functions starting with Grrlib...

So, instead of trying to make it another library you can just create another file under Grrlib and add the functionality there... So it becomes part of Grrlib...

You "libogc addition.zip" is not quite right. It contains both parts that relates to include & lib folder... .h files goes to include and the rest of the code actually become part of the lib... (take a look at libogc folder, you won't find any c files there)

So it's better you try to integrate it with Grrlib... It already has a makefile to build as a library...

Excellent suggestion. Let me see if I understand fully. I keep the original library for the libMii as is and then convert the Miis.h file (which has the various functions) to and additional GRRLIB file (e.g. GRRLIB_mii.h) and store it with the other GRRLIB files. In addition I move all the required image tiles to the GRRLIB area (or most likely a sub-directory of the GRRLIB area). Yes?

Thanks guys. I will play with your suggestions and see what I can come up with. I really appreciate all your help. I am a fairly savy programmer but C is not my strongest language so many times I run into stupid error like this. So I really appreciate you guys helping me out.

I'll keep you posted on progress.

wow, I go away on vacation and LordAshes takes the reins and runs with them... SWEET!

I.R.on... what you said!

That exactly what i was going for as far as my plan of attack. I think what LordAshes is doing is a good idea, i just think that since everyone uses a dif graphics library, we need to keep apples with apples and oranges with oranges... i'll be happy to work with users of other libs to repeat the work, but my plan is do just what was mentioned above... keep libmii the way it is as the key to the mii door, but then package up some additions to each of the graphics libraries to use that key to graphically control things.

People can make their own functions using the new libmii and build whatever special features they want from scratch, and then i'll / we'll have a 'plugin' of sorts for each major graphics library to make it easier for the mid level coders who just want to add support for drawing miis into their homebrew.

/me gets to work!

Quote
mdbrim
wow, I go away on vacation and LordAshes takes the reins and runs with them... SWEET!

Mdbrim,

I hope me running with this is okay with you. Your example was great but I want to get this wrapped up in a nice library of some sort so that the desired Mii can be drawn in projects with only a couple of commands.

To this end...I did exactly as was suggested by other above.

Quote
I.R.on
So it becomes part of Grrlib...

I kept all of mdbrim library work as is and installed exactly as you he indicated.

I then wrote a GRRLIB_miis.h file which basically has most of mdbrim example program code but presented as a few functions that the user can call. I decided to keep all the underlying image files hidden from the user so the user does not need to define any GRRLIB_texImg for the miis. Instead a DrawMii function is provided which handles all the necessary GRRLIB_txtImg work. Basically the GRRLIB_miis.h exposes only a few easy functions for the user to use: one to initialize the miis, one to select a mii (which invokes mdbrim's selection menu) and one that draws the selected mii (at the specified location).

Next is the step that I am not 100% sure about, so please let me know if it should be done differently: I added the prototype for these exposed functions to the GRRLIB__inline.h file and added an include for GRRLIB_miis.h

Originally I had all the .h and .c image files in a subdirectory off the GRRLIB directory (i.e. GRRLIB/miis) but this refused to compile giving me the undefined reference error again. So I got a little upset and stuffed all the array definitions (i.e. the contents of the .c files) into the GRRLIB_miis.h file directly. This seems to have worked. The program compiled. I have not yet had a chance to try it...I have to wait until I get home from work to see it run on my Wii...but at least it compiled and I did not get the undefined reference error.

I would prefer to have the image files in a sub-directory because this would allow them to be modified (if necessary) much easier than if their code is directly in the GRRLIB_miis.h file. I believe that the problem is still, as was suggested above, that during the linking process the .c files in the miis sub-directory are not being processed/linked. Do I somehow need to add this to my MakeFile?

I have repost my re-worked source code. It include a download for the libMii library, the GRRLIB addition and the test program.

BTW, I am aware that the img_body does not work. I am working on this. My guess is that my original file was not a multiple of 4 and thus that is why it is not displaying. But first I need to get the general Mii library working...then I will correct the body and try using all of the other goodies that mdbrim has in the library (such as body type, fav color, name, and creator name).



Edited 2 time(s). Last edit at 04/12/2010 05:21AM by LordAshes.

You should see something in your makefile like:

SOURCES := source
INCLUDES := include

"source" is a directory that contains all your .c files; "include" is a directory that contains all your .h files. If you add a new "miis" subdirectory to the "source" directory, and it contains .h and .c files, then you need to tell the compiler to also look in that directory for .h and .c files:

SOURCES := source source/miis
INCLUDES := include source/miis

Doh! I knew it was something simple that was causing all that headache for me. Thanks...I am sure that is the problem.

Finally I will be able to move the arrays out of the header file!

No no, i have no problems with folks doing their own thing with this... that's the beauty of open source. I just had planned on doing the same thing... either an addon or library that is for each of the current graphics libraries...

IE GRRLIB users would install libmiigrrlib and it would include GRRLIB commands for doing mii's (including body etc)

NON GRRLIB users would use the other lib or addon.

I'm currently working on the grrlib one right now and making some changes to the other variables as well (drawing names under images etc) so it seems we are both working on the same thing at the same time.

Quote
mdbrim
I'm currently working on the grrlib one right now and making some changes to the other variables as well (drawing names under images etc) so it seems we are both working on the same thing at the same time.

Excellent. Carry on. My wrapper will probably be quite simple for very basic users so it will probably not have all the bells and whistles of a proper GRRLIB implementation. For example, a GRRLIB implementation does not really need to hide the GRRLIB_ImgTex variables that hold the Mii or Miis since GRRLIB commonly works with this structure. However, in my wrapper I am hiding all this so that a basic user does not really need to know much about GRRLIB to use it.

So I don't think we are even duplicating effort.

I am looking forward to seeing what you come up with for the GRRLIB implementation.