Re: kextload failure on 10.5
Re: kextload failure on 10.5
- Subject: Re: kextload failure on 10.5
- From: Terry Lambert <email@hidden>
- Date: Thu, 6 May 2010 15:38:48 -0700
On May 3, 2010, at 6:51 PM, Chris Suter wrote:
On Tue, May 4, 2010 at 11:44 AM, Ryan Hankins <email@hidden>
wrote:
So, you must be able to glue the two things together with the lipo
command
once they've been built against separate SDKs... interesting.
Well, that's what happens, but you don't actually need to do it
yourself—the build process does it for you (same as for everything
else).
In other words, as long as you are supporting only 10.4 APIs (that
are still
available on 10.6), you can do this.
Exactly—and I can't think of much that isn't available in 10.6 (32
bit) that was available in 10.4. Obviously, it's a bit different for
x86_64 but that won't be running pre-10.6 so that's not a problem.
Of course, this will skip the symbol renaming that he ran into in the
first place, which means that his code will not be aware of any double
unlocks it does, and so any bugs of that type will ship with his
product, rather than being fixed.
At some point in the future, we will drop support for the unrenamed
compatibility symbol, on the assumption that people have been
targetting the renamed symbol long enough that this is not an issue.
At that point, his driver will start failing to load with an
unresolved symbol for the unlock code. So he will have a perfectly
good 10.6 driver that would have worked on a future version of the OS,
had he *NOT* defeated the symbol renaming.
You really have to consider the consequences of doing something like
building a 10.6-and-later-only 64 bit KEXT with 10.4 header files in
scope instead of 10.6 header files in scope.
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden