Re: Core Audio PowerPC Intel Notes.rtf
Re: Core Audio PowerPC Intel Notes.rtf
- Subject: Re: Core Audio PowerPC Intel Notes.rtf
- From: Marc Poirier <email@hidden>
- Date: Tue, 16 Aug 2005 11:26:49 -0400 (EDT)
On Mon, 15 Aug 2005, William Stewart wrote:
We urge AU developers to move their AU development over to the 1.4.x SDK
as it contains a number of fixes. An AU built with this SDK will still
continue to work on both Jaguar and Panther systems.
Actually, it won't.
There's a couple of points to clarify here. My original statement was not
taking these OS Target macros into account. The intention of this is that the
AU SDK has *no* dependencies that would cause runtime or link errors on a pre
10.4 system (presuming it was built on a 10.4 system). That is still a true
statement: you can compile an AU using our latest SDK and use it on 10.2 or
10.3 with no problem. There are no run-time dependencies in our AU Support
classes beyond 10.2.
Oh yes, I see what you're saying, I was misstating things...
As has been pointed out with previous 1.4.x releases, they won't build with
a 10.2.x SDK because of kControlStaticTextIsMultilineTag in
AUCarbonViewControl.cpp
We just built the view targeting 10.2 or later and it builds fine. In fact
the constant kControlStaticTextIsMultilineTag is defined in 10.1 (look at the
comments in Carbon/ControlDefinitions.h). So, I'm confused by this statement
as it is fine for us.
Hmmm... then I guess it is a dev tools bug, cuz the MacOSX10.2.8 SDK (as
installed by Xcode 2.0 and 2.1) is missing it in its version of
ControlDefinitions.h (I will re-report the problem as such).
in order to build with a 10.2.x SDK, and building with a 10.2.x SDK is
necessary for making an AU that will run in Jaguar.
No this is not true. All that these macros will really do is to give you a
compile error if you are referring to something that was not implemented on a
particular version of the OS. But if you "know" that you are not using newer
API, then whether you use these macros or not, your code will run (or not!).
There are of course a collection of headers that don't and will never use
these macros (BSD for instance) that has substantial differences. Yes, its
helpful, but its not necessary.
Unfortunately, though, that's not the end of it. The problem really is
with the standard C++ library in Mac OS X. Up until 10.4, it has been a
static library, and code built with one milestone version's don't run in
previous milestone version's (10.3's can't run in 10.2 or earlier, 10.2's
can't run in 10.1 or 10.0, etc.). Tiger switched to using a dynamic
library, which is great because now that won't be a problem anymore, and
10.3.9 includes with dynamic library support too, but unfortunately the
problem still remains for the earlier versions of the OS. So if you want
your C++ code to run in 10.2, unfortunately you need to use the 10.2 SDK,
not because of the headers, but because of the standard C++ library. This
also unfortunately ruins Xcode's whole support for weak linking and such,
but anyway, that is going further off-topic...
rdar://4215634
OK - so here's what we'll do. Going forward, we will make sure that the AU,
AudioFile and AudioCodec components will build in our latest SDK with earlier
OS releases targeted - we'll also indicate when/if there is any change in
these areas to the base level OS requirements. This will STILL assume that
you are building on Tiger (or later) of course. This will give you what you
are want I think.
Not exactly, cuz what I am saying is that, for 10.2 support, they will
need to be able to be built with the 10.2 SDK. But as you pointed out
above, you're right that the things I'm mentioning are not runtime
dependencies, and therefore my suggested changes aren't actually the best
options. You don't necessarily want to just remove those blocks of code
from building at all just because you're want your software to run in
10.2. Now that I think about it more, I see that the ideal is to have
those CoreAudio constants that aren't defined in the 10.2 SDK to be
defined in the case when building with the 10.2 SDK. And after saying all
of this, now I'm just kinda thinking that maybe the best solution is for
developers to just modify their own headers in the 10.2 SDK to add the
missing constants in. That's a completely safe modification to make, and
it would solve the problem. Maybe there's a better solution, though...
thanks,
Marc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden