site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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). 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. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On May 3, 2010, at 6:51 PM, Chris Suter wrote: On Tue, May 4, 2010 at 11:44 AM, Ryan Hankins <rqh@small-tree.com> 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. In other words, as long as you are supporting only 10.4 APIs (that are still available on 10.6), you can do this. 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. This email sent to site_archiver@lists.apple.com