I have a filter scheme driver with four binaries for 10.4 PPC, 10.4 i386, 10.5 & 10.6 i386 and 10.6 x86_64. I need to put them all into one kext. I don't think I can just lipo them together because of the two different i386 binaries.
How can I get them all into the same kext bundle?
See Apple's SimpleUserClient example: you can use sub-kexts for each OS revision.
Note that you may need to tweak the build settings a bit because later ld versions insert a load command that the earlier kernel linker doesn't understand; see this mailing list message (and the surrounding thread, if you need more context).
(Why on earth was this question marked "non programming related"?)
If you have four separate binaries, you cannot put them into the same kext bundle. You can put up to two binaries into a bundle by putting one bundle into the Plugins directory of the other bundle; the Plugin will match if the inital driver does not. However, if there are no API changes between your kexts, you may be able to use a kext compiled for 10.4 on 10.5 and 10.6, or one compiled for 10.5 on 10.6.
Related
SDL uses some functions that no longer work using the MacOSX10.7 SDK. I am not very familiar with MacPorts and I would like to know if there is a way to tell macports to build SDL using the 10.6 SDK instead.
If this is not possible, I can download the source and compile it myself, but again, I am not familiar with how to set the flags that I need. I would like a 32-bit build of SDL that uses the 10.6 SDK but runs on Lion.
I have successfully built SDL framework for ppc, i386 and x86_64 using the following diff: http://r.research.att.com/sdl-1.2.14.diff
and the project in SDL-1.2.14/Xcode/SDL/SDL.xcodeproj. The diff uses 10.5 SDK so if you don't have that, you can simply change the 10.5 line to 10.6 and remove ppc.
If you don't want to build it, a binary is available at http://r.research.att.com/libs/SDL-1.2.14-fw-darwin9-bin3.tar.gz - it works on OS X 10.5 and higher (i.e., including Lion).
(I gave up to trying to fix the configure + make build which is broken for OS X since it has a lot of stuff hard-coded that is many years out of date, because I needed it quickly...)
I am using XCode 3.2.6 on an Intel Mac running OS X 10.6, to build a fairly simple app that needs to be able to run under OS 10.4 on a PPC-based Mac, in addition to modern Intel-based Macs.
Under the project settings, I only see options for 32-bit Intel, 64-bit Intel, and Standard (32/64 Intel). Should I be seeing a "Universal Binary" entry here?
I don't have any problem running it under 10.4 on an Intel Mac. I was careful not to use features that don't work under 10.4, and I think I set the project settings correctly to allow it to be backward-compatible to 10.4. It's just that I can't figure out how to get it to compile for PPC.
I'm flailing around, trying to figure out how to build a universal binary, and I think I'm probably just missing something obvious. Any help would be greatly appreciated.
You don't have to choose one of the predefined settings for the Architectures build setting. You can choose "Other..." and then explicitly enter a list of architectures like ppc, i386, x86_64.
By the way, there are extra tricks if you need to run on G3s: You must use GCC 4.0 and the 10.4 SDK.
I am trying to build a universal binary for a project at work, but I can't seem to get Xcode set up properly to do so.
I am familiar with the Apple Documentation regarding this, but apparently I am not reading it correctly.
The Xcode build options in question seem to be:
Architectures
Base SDK
C/C++ Compiler Version
Mac OS X Deployment Target
In my settings I have the following Valid Architectures: i386 ppc ppc64 ppc7400 ppc970 x86_64.
If I use the following options, I get a binary with i386 and ppc970:
Architectures: i386 ppc
Base SDK: Mac OS X 10.5
C/C++ Compiler Version: GCC 4.0
Mac OS X Deployment Target: Mac OS X 10.5
I have several questions about this:
Why ppc970 and not ppc7400 (or simply ppc)?
What is the difference between the ppcs (ppc, ppc64, ppc7400, ppc970)?
How do I get a binary for any ppc?
Apparently, I need a binary with ppc7400 to work on the Mac Mini we have for testing. The Mini has a G4 and is running OSX 10.5.8. From what I can tell, a binary with ppc7400 works but not one with only ppc970.
I have tried several combinations of the above build options, including changing my Base SDK to 10.4u. The above configuration is the only one that even builds. Other builds fail, often because of not recognizing header files or clearly available #defines. For example, if I change my compiler to gcc 4.2, I get errors searching for stdarg.h because of the #include_next directive and no clear path to correct headers. If I drop my Base SDK to 4.0, #define FSIZE long long is no longer recognized despite not changing any includes.
I'd really appreciate any insight you can give me on this.
EDIT UPDATE
Thanks for the info. I understand the flags now. But I get a strange result.
These are my build flags now:
GCC_VERSION = 4.0
MACOSX_DEPLOYMENT_TARGET = 10.4
SDKROOT = macosx10.5
GCC_MODEL_TUNING = G3
This produces object file (.o) that have arch 'ppc' as shown by lipo. All the included libs and frameworks are either 'ppc' or 'ppc7400' (again as shown by lipo). But, the final build is 'ppc970'.
I have gone over this very carefully to ensure I got everything. Can anyone think of a reason for the ppc architecture differences?
I've even gone so far as to create a new project (Hello World) and link it to all the libs and frameworks of the first project. Hello builds as 'ppc' not 'ppc970'.
This just makes no sense to me.
ppc970 == G5. If you need to support as far back as the G4 then just build for ppc7400.
Rather than messing with individual architecture settings, though, you can just select 32-bit Universal (or Standard (32/64-bit Universal), if appropriate) from the popup menu, and that should give you what you need.
In target settings make below changes..
GCC_MODEL_PPC64 = NO
i.e., uncheck “Use 64-bit integer Math”.
Enabling will turn on 64 bit. So it will be G5 onwards..
When I pass compiler flag -mmacosx-version-min=10.5, what does it mean? I think it implies the result binary is x86, not ppc, but is it 32 bits or 64 bits? I'm compiling on snow leopard, so default output binary is 64 bits. I'm not passing -universal, it's not 32bit-64bit universal binary, I think.
This option will be used by the various availability macros placed into the headers. This means that you can require a minimum version of OS, even if you have a more recent SDK (i.e. target 10.5 with a 10.6 SDK). Using a 10.6 API while targetting 10.5 will trigger a warning and the API will be linked with a weak_import attribute.
Most Apple's API headers contains availability macros for each class, methods, functions or enumerations in order to declare for each of them:
The minimum OS supported
The deprecation
The unavailability
...
The macros look like:
AVAILABLE_MAC_OS_X_VERSION_10_2_AND_LATER
AVAILABLE_MAC_OS_X_VERSION_10_2_AND_LATER_BUT_DEPRECATED
...
As for the architecture, it only depends on the available architectures in the binaries of the SDK. For example with a 10.5 SDK, you can target four architectures (Intel/32bits, PowerPC/32bits, Intel/64bits, PowerPC 64bits), while with a 10.6 SDK, you can only target three architecture (Intel/32bits, PowerPC/32bits, Intel/64bits).
As you are using Snow Leopard, you can either target i386 (Intel/32bits), ppc (PowerPC/32bits) or x86_64 (Intel/64bits) very simply by passing an architecture option like this:
gcc -arch i386
or like this (for configure-based projects):
CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure
-mmacosx-version-min=... also influences the default choice of C++ STL implementation (GNU or LLVM), and in this regard, it is equally important for the compiler and the linker.
From my testing, it's also important that this option be passed to the link step (like -arch); so it does more than affect macros/preprocessing (as might be inferred from other answers).
When passed to compile step but not passed to the link step, I found that shared libraries built with 10.6 would not load under 10.5.
It triggers compiler warnings for methods that appeared after Mac OS X 10.5. Is has nothing to do with architecture.
I have a MacBook Pro with a 64-bit Intel Core 2 Duo processor, and I'm using gcc (i686-apple-darwin9-gcc-4.0.1) to compile executables which I can run ok on my own machine. Recently someone tried to run my application on a PowerBook G4 and got a 'Bad CPU type in executable' error, which I think is because their CPU is PPC rather than Intel (and also possibly 32 bit not 64 bit)
Is it possible for me to produce binaries that will work across all the various Mac architectures using gcc, and if so what options do I use?
Look at the -arch parameter for gcc Apple docs
You need to look into "Universal Binaries" this is the name given to an app file which runs, with no dynamic recompilation, on both ppc and i386 architectures. As you know .app files (Mac Executables), are in fact archives, which contain, within them, the actual binary application. These can be partitioned in such a way that both the i386 and ppc binaries are contained.
To save yourself and your users future headaches, you should bite the bullet and set up your project in Apple's Xcode. If you follow the defaults, Xcode can take care of all the details of building for multiple architectures, like using the proper -arch flags for gcc, using the correct SDK libraries, compatibility with previous OS X versions, etc etc.