Game Development Community

Strange Xcode problems

by Leo "kingDUCTtape" Altmann · in Torque Game Engine · 05/08/2004 (5:19 pm) · 41 replies

I have been working with torque for a few months now, and using Xcode I've never really had any problems. But now, for some reason, whenever I try to compile, it fails due to one error:
Undefined symbols: _vorbis_info_blocksize
Obviously this is some problem with the ogg code. But the weird part is that it says Location: pb:0. When I double-click it, it just opens the pb folder. I re-downloaded the entire head from CVS, and tried compiling it w/o any source changes, and it still gave me this error. Ideas?

EDIT: By the way, I'm running OS X 10.3.3, on an iBook G3 800MHz.
Page «Previous 1 2 3 Last »
#1
05/09/2004 (7:15 pm)
Weird. We just got the ogg stuff cleaned up a bit like two weeks ago and things were running fine. I'll have a look at this on Monday, unless someone has encountered the problem before and knows what's going on.
#2
05/09/2004 (8:08 pm)
I'm compiling for the first time and I get that error as well:
pb:0: Undefined symbols: _vorbis_info_blocksize

This is the only error I get when I compile and 39 warnings but no executable scripts are generated in the /example directory so I still haven't been able to play with Torque on my mac yet :(


- Jordan
#3
05/09/2004 (11:37 pm)
Crappy. Sorry about that. I'll definitely take a look at this in the morning.

Jordan, are you downloading the HEAD version as well?
#4
05/10/2004 (9:05 am)
Well, I just downloaded head and compiled with no problems. I'll continue trying to break it though. :)

It shouldn't really matter, but have you both updated to XCode v1.2? It was just released about 3 weeks ago.

I'll continue looking into this, but I just want to warn that it might take a while, since I can't reproduce it on my own machine right away.

Edit:

Let me make sure too... are you guys setting the XCode Menu -> Preferences -> Building tab -> Separae Location for Build Products option? It should be set to ../example

Also, are you both building Debug or Release? Or have you tried both?

Thanks for the additional info, just trying to figure out how to reproduce this.
#5
05/10/2004 (10:01 pm)
Yes, I have set the directory to ../example, and I tried both debug and release. I have not yet updated to XCode 1.2, mainly since the only version I could find when it came out was the segmented one (21 segments!!!!!!), but I guess I'll go start the mammoth downloads... I'll see if it works then. (though it used to work with this version of XCode)
#6
05/11/2004 (1:16 am)
I've been having the same problem. I'm using 10.3, xcode 1.2, and I have the directory set to example.
#7
05/11/2004 (11:07 am)
Fudge. Leo, yes it probably has nothing to do with the XCode version, I was just checking.

I was not able to reproduce this. This probably won't help either, but have you guys tried running ranlib on libogg.a and libvorbis.a as per the Mac FAQ and readme file?

Let me know. That probably has nothing to do with it either, but I'm kind of drawing at straws here, since I can't get this to happen on my machine.
#8
05/11/2004 (11:31 am)
No luck running ranlib on libogg.a or libvorbis.a, it's one of the first things that I'd tried.
#9
05/11/2004 (12:38 pm)
Thanks Christopher.

Hmm... if you investigate the project settings, are all the library and framework paths relative? (eg ../lib/vorbis/) XCode always seems to want to make them absolute, and that *may* be screwing something up. Also, just as a sanity check: if you look in the libraries section in the project browser, is libvorbis.a listed? And if you "show info" on the file, is it specified relative to the project directory?
#10
05/11/2004 (5:56 pm)
No change...I've checked everything. I think I will try using a fresh download of the HEAD.
#11
05/12/2004 (12:44 am)
So, the libvorbis.a file is referenced in the library section, and the file, library and framework paths are all relative?
#12
05/12/2004 (3:58 am)
Yes, checked everything.

Odd...downloaded the HEAD and it compiles fine now (aside from 38 warnings). Not sure why, I hadn't made any changes to the code, but it works now.
#13
05/12/2004 (4:46 pm)
Weird. I didn't change anything :)

Well... I wonder if Jordan and Leo are getting the same thing?
#14
05/15/2004 (7:09 pm)
Ok. I have re-downloaded the head for a second time, updated to XCode 1.2, downloaded all the latest updates, and danced a jig in front of my screen chanting "work, slimeball!", yet I'm still getting that infernal error. Has anyone gotten any further on a solution?
#15
05/16/2004 (5:43 am)
Are you sure you haven't made any modifications to the code....I've determined that my problems had to have originated from some of the modifications I had made somewhere along the line, though I can't really be sure. When I reinstalled XCode and brought in a clean version of the HEAD it compiled fine. Maybe running ranlib a second time on both of the OggVorbis .a files helped also. Regardless, I don't seem to be having any other problems...as a matter of fact I've since integrated the Synapse Lighting pack without any real problems. I have to lean towards Josh's opinion here and believe that it has to do with the audio framework/files not being referenced correctly.
#16
05/16/2004 (10:10 am)
This is an unmodified version of the head. I have tried everything. Paths relative and aboslute. Running ranlib on the libogg.a and libvorbis.a multiple times. Tried both debug and release. Is there anything left for me to try short of re-installing XCode? Probably not, so I'll go do that now...

EDIT: THIS IS PATHETIC!!! I just re-installed XCode, got yet another un-touched version of the HEAD, and it still gives me that error.
#17
05/16/2004 (12:28 pm)
Leo,

I'm still not sure what's going on. Clearly, there is something somewhat unique about your setup that is causing errors.

Of course, I'm not saying it's your fault that there are problems. I'm just not sure how to help you fix them, since I can't get it to reproduce, and I'm unable to identify the cause of the problems so far.

Let me ask: do you have any spaces in your directory names? That's just a shot in the dark, it shouldn't really have an effect, especially if relative pathing is used everywhere, but maybe it's worth a try.

Can you think of any OSX settings that might affect path linking?

Did you tell XCode to put build products in the ../example directory? Again, that shouldn't affect the ability to compile, but I'm kind of grabbing at straws here. Any other info you have will be helpful.

Sorry that it's so frustrating. Another thing to try, just to test, would be to delete the references to libogg.a, and libvorbis.a from the project altogether. Then try compiling. You should get the above error and more. Then re-reference the libraries. There is no good reason why that should work, but again, we're grabbing at straws here unless we can identify what specifically about your set-up is making XCode barf.
#18
05/16/2004 (5:25 pm)
What really stumps me is that it used to work just fine! Then suddenly for no apparent reason, it just started giving me the error.

EDIT: Well, I tried removing the libogg.a and libvorbis.a and re-adding with no success. I also did a little looking thru of the code, and found that _vorbis_info_blocksize is never mentioned at all in the code! Seems weird that an error is appearing, yet it's never mentioned in the code at all...
#19
05/16/2004 (8:04 pm)
Yet another strange thing. I tried downloading the HEAD and compiling it without even running ranlib. I expected to get the message telling me to ranlib the libraries, but instead I got the same error. Does this maybe narrow down the possibilities?
#20
05/17/2004 (12:49 am)
Leo,

Are you sure that vorbis_info_blocksize isn't defined anywhere? It should be in the files codec.h and vorbisStream.cc.

If not.. that is wacky. Another thing to try (again, shot in the dark here), if it is defined in these files, would be to comment out the lines referring to that data (there are only two), and attempt to compile then.

If nothing else, this might help us narrow down the problem. Please note, if the engine compiles with those lines commented out, you and I will still want to look into what the cause of the error is, and fix it. It wouldn't be good to just leave these lines out.
Page «Previous 1 2 3 Last »