Ok so the first problem is that GetRefAPI isn't actually in cl_main.c. What
is in cl_main.c is this:
Code:
ret = GetRefAPI( REF_API_VERSION, &ri );
That is just a call to the function. What we need is the definition of the function. I searched the GitHub, and it shows up in various places. For example, in tr_public.h we have this:
Code:
refexport_t*GetRefAPI( int apiVersion, refimport_t *rimp );
But that is not a definition, that is a
declaration. A declaration just says "hey there's a function called GetRefAPI and here's the signature. You can call it, but since I don't have the code for it, the linker is going to have to figure this out."
A definition is where the code actually occurs. That is in code/renderer/tr_init.c. Which you can see here:
Code:
refexport_t *GetRefAPI ( int apiVersion, refimport_t *rimp ) {
static refexport_t re;
...
}
What this means is that the important object file is going to be tr_init.obj. For any given symbol (function, variable, etc) exactly one object file should contain a symbol for it. That's what I was getting at with the dumpbin commands. I was trying to see "does this object file have the right symbol?" If it does, and the name is correct, you won't get an unresolved external.
So when diagnosing this kind of thing, you have to ask:
1) Which object file contains the definition
2) Is that object file being linked in
3) If not, why not? If so, why isn't the name matching?
So now that we know it
should be in tr_init.obj we go back and look at the link line
again. This time we're looking for tr_init.obj. And we see, it is nowhere to be found.
So this brings us to #3 above. The proper object file is not being linked in, and we need to know why.
I went to the top level of the GitHub repo and saw that there is a
quake3.vcproj file. I opened it up in GitHub (not in VS), and Ctrl+F'ed for
tr_init.c found that this project does not even compile this file. So it needs to be coming from somewhere else. Probably it's compiled in a different file and then supposed to be linked in to the final project. So I opened the .sln instead and saw that there is another project called renderer/renderer.vcproj and sure enough, this is the project that compiles tr_init.c.
So now we have a clue. quake3.vcproj is supposed to be linking in the files from renderer.vcproj, but it isn't. How is it supposed to link them in? Well, in renderer.vcproj we see this line:
Code:
OutputFile=".\Debug_TA\renderer.lib"
So we can tell that it is supposed to be outputting a file named renderer.lib, and presumably this file is supposed to be linked into the final executable. Remember one of the first observations I made when I looked at the link line was that there are no quake-specific libraries.
So to fix it. The first thing to check is: Did you open quake3.sln or did you open quake3.vcproj? If it's the latter, that's the problem. Open the .sln file instead. However, I suspect you are already opening the .sln file.
This could be an issue with such an old version of the MSVC project file format not fully forwards-compatible with the new version, so when it tries to upgrade, information is lost. The reason I suspect this is because I don't see anything in any of the project files or solution files to indicate that quake3.exe (from quake3.vcproj) should try to link renderer.lib (from renderer.vcproj).
If you just want to test this theory out, go into quake3.vcproj, edit project settings, go to Linker and find Additional Input files then add a full absolute path to renderer.lib on your hard drive.
I suspect the errors will go away. If you want to do it the "right" way, probably in the solution file you need to add a dependency from quake3.vcproj to renderer.vcproj, and then in the Configuration Properties > Linker > General for the quake3 project, make sure "Link Library Dependencies" is set to Yes
