Re: AU - CW code gen problems
Re: AU - CW code gen problems
- Subject: Re: AU - CW code gen problems
- From: Marc Poirier <email@hidden>
- Date: Thu, 27 Mar 2003 22:12:20 +0100 (CET)
>
Firstly, if you're not using CW8, you're just flat out of luck; CW7 and
>
older all had minimal (if not no) Mach-O support. If you are, that's
>
one hurdle.
Jumped. I'm using 8.3. I'm also doing other things the way you're
suggesting, except:
>
Secondly, make sure you're NOT using MSL in any way other than the MSL
>
runtime lib. The process for this is to delete the MSL access paths
>
from the target, move the OS X Support path down below the framework
>
path, remove the MSL All (or MSL C/C++ libs) from the project, and add
>
the MSL Runtime Mach-O.lib to it (if necessary). Make sure you have
>
crt1.o (or whatever the appropriate one, like dylib1.o is) in the
>
project, and that it links first, and that MSL Runtime links last.
Using MSL_Runtime-Mach-O.lib (I do need it) and bundle1.o, but I'm not
sure what to do about the MSL includes. I can't figure out a way to build
without them. Some of the Apple AUBase* source files include headers like
vector which I only have copies of either in
/usr/include/gcc/darwin/3.1/g++-v3/ (and the 2.9 equivalent) or
MSL/MSL_C++/MSL_Common/Include/ and when I try the gcc ones, CW won't
build them spitting out lots of errors in those headers (which is no
surprise, it doesn't seem too wise to me to try to include headers written
for a specific compiler, one which I'm not using). So anyway, I'm stuck
with the MSL headers. And then those require some other MSL headers, so
what I wind up doing is also adding MSL_C/MSL_Common/Include and
MSL_C/MSL_MacOS/Include to the end of my search paths, too.
But here's the crazy thing: After another day of maddening debugging
(nonsensical crashes constantly), I finally decided to try building with
completely skeletal code. Every AU API method, I went in and put return;
on the first line. So in other words, every method returns immediately,
none of my code is reached, nothing happens. I've also turned all
compiler optimizations off. And guess what? It still crashes.
So now I'm wondering, why do you caution so strongly against using any MSL
include paths? I'm doing it, and I'm getting insane crashes. So
basically all I can figure at this point is that CW is really going
haywire or I'm doing something fatally wrong by using MSL includes. And
if it's the latter, and anyone can suggest how I can proceed without MSL
includes, I'd muchly appreciate it!
>
And just as an aside, do the crashes you experience have a common
>
ancestor in their call chain when you look at the stack trace?
When running in AUHosting, it varies a lot. Very often, the traces don't
look like they have anything to do with my code. It's most often from
destroying the window or from handling some events. But it varies a lot.
Sometime the crash occurs in a GenericAUView class, which makes no sense
at all. But in Logic, it's 100% repeatable: crash occurs in
CarbonEventHandler.cpp TheEventHandler() upon receiving kEventClassWindow
kEventWindowClose, and then calling handler->HandleEvent(inEvent) crashes
because the pointer to handler (passed in as inUserData) is bogus (I know
because I added an empty method to the CarbonEventHandler class and
calling that from handler also crashes; the pointer is not null, though).
Thanks for walking through my hell with me,
Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.