Re: Building pre-tiger kext under tiger
Re: Building pre-tiger kext under tiger
- Subject: Re: Building pre-tiger kext under tiger
- From: Chris Espinosa <email@hidden>
- Date: Thu, 14 Jul 2005 08:09:51 -0700
On Jul 14, 2005, at 12:06 AM, Andrew White wrote:
Check out the "Cross-Development" documentation:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
XcodeUserGuide21/Contents/Resources/en.lproj/
05_10_bs_cross_development/chapter_37_section_1.html The high points:
- install the Cross-Development SDKs from the Xcode 2.1 installer
- set the "Cross-Develop Using" setting in the Project's Get Info,
General tab
- set the "Mac OS X Deployment Target" build setting to the earliest
OS version you wish to run on
- set up the target's Rules to use the appropriate compiler version
for your target (gcc 2.95.2 or 3.3 for KEXTs on 10.2.8)
OK, I think I'm 80% of the way there. That said, when I compile I'm
still looking in the wrong version of Kernel.framework, as evidenced
by all these undefined symbols. How do I make sure it uses the 10.3.9
SDK version?
I've set:
- Project "MyProject" Info: Styles: General: OS X Deployment Target =
10.3
- Project "MyProject" Info: General: Cross-Develop SDK = 10.3.9
- Target: MyTarget: GCC compiler settings = 3.3
(and yes, I've checked that the SDK is installed)
It should be possible to find the necessary stuff...
"fgrep socreate /Developer/SDKs/MacOSX10.3.9.sdk/System/
Library/Frameworks/Kernel.framework/**/*.h" finds the function.
I just can't convince gcc/Xcode to search there for libs and libraries
rather than in the default location.
I notice the docs refer to a prefix file, but I don't have one.
Should I? What should it be for a .kext?
When an SDK is in use, Xcode (and gcc and ld) preface all system paths
(/Library, /System, and /usr) with the value of $(SDKROOT), which is
set in the SDK popup. If it's failing to do that in some case, it's a
bug; you'll have to post your whole build transcript for us to help you
find the problem. If you find a path that is going directly to the
root headers instead of the SDK, you might try manually adding
$(SDKROOT) to the beginning of the path by which it's found.
Adding -v to the Other C Flags build setting produces diagnostic output
from gcc about where it's searching for things. That's often helpful
in figuring out what's wrong.
If you have other special operations (like shell scripts) that refer to
system headers or libraries, it's a good idea to manually add
$(SDKROOT) to the beginning of their paths.
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden