Game Development Community

HEAD not building on OS X...

by Joel Miller · in Torque Game Engine · 08/22/2002 (10:17 pm) · 14 replies

Has anyone else run into this problem?

I'm using the April 2002 Developer Tools on OS X (10.1.4), ../lib/ljpeg/jmemmac.c produces these messages:

/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:20: header file 'CarbonCore/MacTypes.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:24: header file 'CarbonCore/MixedMode.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:28: header file 'CarbonCore/OSUtils.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:32: header file 'CarbonCore/TextCommon.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:36: header file 'CarbonCore/UTCUtils.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:42: header file 'CarbonCore/Finder.h' not found
/System/Library/Frameworks/CoreServices.framework/Versions/Current/Frameworks/CarbonCore.framework/Headers/Files.h:66: undefined type, found 'UInt16'

#1
08/22/2002 (10:59 pm)
HEAD should only be used for keeping up-to-date with current bug fixes and such, I would recommend that you use the latest Release for compiling and just use HEAD for code modification updates since this is the best way to make sure it'll at least compile much less run. ;)
#2
08/27/2002 (7:58 pm)
I certainly built on OSX since April (probably may/june), assumedly with recent tools but possibly not given the problems you are seeing.

I know that one BIG issue is that I haven't updated the project file on the Mac in a while -- I hand-edited in a file change, but there's a pre-include header in both targets that shouldn't be there. Unfortunately, my project builder setup isn't working at the moment, so I have no easy way to fix. I'll try to see if I can do another hand-edit to remove the header force-include.

d
#3
08/28/2002 (1:23 am)
Tell me what to look for. I'll take a whack at it.
#4
09/04/2002 (8:09 pm)
I might have already removed it...

The project definition (well, the target defn) had a header file that was either macCarb_debug_prefix.h or macCarb_release_prefix.h. Each of the targets had the respective pre-include defined in the project panel. Those headers are no longer needed/used.

HOWEVER, if that stuff is gone, I have no clue. Possible there's a header ordering problem, which means Apple changed something about the headers either in the newer OS (I think I'm on 10.1.4 still) or the new tools changed something.

Stuff was working earlier in the summer, that's for sure... ;)

d
#5
09/05/2002 (12:13 am)
I'm now running on 10.2 GM with its dev tools (July 2002; PB 2.0.1 using GCC v3.1). The earlier errors went away and were replaced by this single error (unfortunately it is also in a system header, OpenTransport.h):

Quote:
In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:45,
from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:25,
from /System/Library/Frameworks/ApplicationServices.framework/Versions/Current/Frameworks/QD.framework/Headers/QD.h:20,
from ../engine/PlatformMacCarb/platformMacCarb.h:20,
from ../engine/platformMacCarb/macCarbCPUInfo.cc:8:
/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OpenTransport.h:4245: function 'void* operator new(long unsigned int)' is initialized like a variable

Since it seems that it happens as a result of including the QuickDraw header, maybe we should consider dropping QuickDraw in favor of Quartz. =-)

I just started a build using the old GCC v2.95.2, I'll post an update if that changes anything for the better.

Joel
#6
09/05/2002 (12:27 am)
No dice: Same error. =-(
#7
09/05/2002 (10:13 pm)
I had to do some fiddling, that I hope hasn't broken any older configurations, but it works for building under OSX 10.2 with July 02 toolset.

I tested building CW7 project CFM/Carbon target works fine, but MachO target won't build -- I'm NOT going to fix that at the moment, since anyone wanting a pure MachO build can use PB at this point.

I'm checking in a new 10_2 project file so as to not break the 10_1 file. However, it is possible the changes I made in the headers for compilation won't work for some reason under 10.1+tools.

d
#8
09/12/2002 (12:43 am)
David:
Thanks for the fixed project files. Now there's another problem =-) :

The demo app displays the stop alert: "Failed to open main.cs.". Then it quits. Yes, I am running it from the "example" folder where main.cs is located =-).

I tried pausing execution during the alert, and putting breakpoints in main.cc-->initGame(), but PB 2.0.1 doesn't even show me anything for the call stack. (I'm assuming that the lack of a call stack is a bug in PB, and I've posted a question about it on the ProjectBuilder-Users mailing list that Apple provides.)

Unfortunately, since PB isn't even showing me call stacks, I am unable see why TGE cannot open main.cs...

I'm hoping beyond hope that this is a problem unique to my system/configuration, and that someone can point me in the right direction to get things going...

Thanks!
Joel
#9
09/12/2002 (8:44 pm)
If you are running from within PB, you need to set the executable directory for the target to point to the newly-built local app. This is one failing of the PB system that I haven't found a way around yet. But I thought this issue was clearly doc'd in the original README in the PB dir, no? Anyway, that's the problem -- if you run from within PB without setting the executable path, you're running it to the production path... and have no data files.

d
#10
09/12/2002 (11:22 pm)
Ok, stupid me, I mistook the path under the "Runtime" section for the path you're talking about. However, the app now gets EXC_BAD_ACCESS, and I still can't see anything in the PB debugger.

Do you know offhand if TGE can be built under CW Pro 5? I really can't spend the six hundred for Pro 8 (they don't give upgrade pricing to CW Pro 5 users =-( ).
#11
09/14/2002 (12:25 am)
It looks like what's left is partly a Project Builder bug and partly TGE. I'm talking with the Dev Tools engineers at Apple to find out what's wrong with PB.

In the mean time, I've resorted to using Terminal.app and gdb from the command line, and there IS a bug in TGE on OS X. Here's the message from gdb:

Quote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0004d5b8 in ResManager::setModZip(char const*) (this=Cannot access memory at address 0x6d706d2d) at ../engine/core/resManager.cc:355
355 for(U32 i = 0; i < pathInfo.size(); i++)
#12
09/14/2002 (12:32 pm)
I've filed a bug (bug #00068) regarding the memory access error listed above.
#13
09/18/2002 (8:17 pm)
Must admit I'm a bit confused. Last I left off, I had a 10.2 project building, and the resulting executable runs fine -- though granted, I wasn't trying to launch it from within PB.

I just tried it, built fine (from my 10 day stale codebase here), manually double-clicked the app and it launched in windowed mode, got into a mission just fine. Audio works, first and third person, effects, reflections... seems to be pretty good here.

What's your system again?

Note that the mac projects are NOT currently up with the head, as some files recently changed on the PC side and I haven't had time to update the projects with those changes.

d
#14
09/19/2002 (5:12 am)
It's a QuickSilver 733, stock HW except for having 1.5 GB Ram. See bug 00068 for detailed specs.