[Topic]If you've already downloaded Xcode 2.1, and you've compiled a program for the Intel architecture, shouldn't Get Info in the Finder let you see the type of Architecture that the file was built for? I've tried this already, but it is not showing up in the Finder. Maybe this is only when running OS X on Intel? Because you can choose whether you want an app to compile as Intel OR PowerPC, so you think the option would be available under OS X for PPC. Correct me if I'm wrong.
You can determine whether an application has a universal binary by clicking the application icon and pressing Cmd-I. In the More Info section of the Info pane for the application, the Architecture entry (see Figure 1-3) lists whether the binary is Intel, PowerPC, or both Intel and PowerPC.http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf (page 18)----I've tried to compile an x86 binary, but it won't link because all of the system libs are ppc only. I don't think we will see that arch listing until at a minimum an os update, and probably until OSX ships with the dual-compiled libs to link against (and actually have a binary where it's worth displaying the varying architectures.)you need to build against the 10.4 (Universal) SDK----I also got this same warning and figured out what was wrong. There are two info windows involved when setting this up. The project info window and the target info window. The documentation "e6mphy-universal_binary.pdf" starts out by having you configure your project by changing settings in the "Project" info window (the one that opens when you double click on the project icon at the top of the Groups and Files outline view).'Then you are asked to change the Architectures setting by following some more steps. In step 4:4. In the Build pane (see Figure 1-1), choose Release from the Configuration pop-up menu.you are asked to select the "Release" menu item. XCode version 2.1 that I downloaded 6/6/05 did not have this menu item. To make this warning go away you have to manually turn off Fix and Continue and ZeroLink in the "Target" info window (the info window that opens when you double click on the name of your target in the "Target" group folder). --zootbobbaluThat popup can be added to the Project window toolbar, or it is on the Build Results window... or you can choose it from the Project menu Set Active Build Configuration Tried building a small app using the instructions given in that page, but when trying to compile a universal binary, there are a bunch of build warnings and errors
/usr/bin/ld: warning /System/Library/Frameworks/Cocoa.framework/Cocoa cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded)/usr/bin/ld: warning fat file: /usr/lib/gcc/i686-apple-darwin8/4.0.0/../../../libmx.dylib does not contain an architecture that matches the specified -arch flag: i386 (file ignored)/usr/bin/ld: warning fat file: /usr/lib/gcc/i686-apple-darwin8/4.0.0/../../../libSystem.dylib does not contain an architecture that matches the specified -arch flag: i386 (file ignored)/usr/bin/ld: warning fat file: /usr/lib/libSystem.B.dylib does not contain an architecture that matches the specified -arch flag: i386 (file ignored)/usr/bin/ld: Undefined symbols:___keymgr_dwarf2_register_sections__cthread_init_routine_atexit_errno_exit_mach_init_routine_NSAddressOfSymbol_NSLookupAndBindSymbol_abort___sF_fflush_fprintf_memcpy_memset_pthread_once__keymgr_get_and_lock_processwide_ptr__keymgr_set_and_unlock_processwide_ptr__keymgr_unlock_processwide_ptr_calloc_free_getsectdatafromheader_malloc_NSAddImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSCreateObjectFileImageFromFile referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSGetSectionDataInObjectFileImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSHasModInitObjectFileImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSInstallLinkEditErrorHandlers referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSLinkModule referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSLookupAndBindSymbol referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSSymbolDefinitionCountInObjectFileImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSSymbolDefinitionNameInObjectFileImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib___sF referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_get_image_header referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_get_image_name referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_image_count referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_register_func_for_add_image referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_abort referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_fprintf referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_getenv referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_getsectbynamefromheader referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_malloc referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcat referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcmp referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcpy referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSAddressOfSymbol referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSFindSectionAndOffsetInObjectFileImage referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSIsSymbolNameDefined referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_fwrite referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_calloc referenced from ZeroLink expected to be defined in /usr/lib/libSystem.B.dylibcollect2: ld returned 1 exit statusand yes, I set it to 10.4 Universal SDK....Did you compile against the correct frameworks? Looks like you're missing some basic stuff human error ;)I sure did. It's an app that compiles just fine. Once I follow Apple's directions, it doesn't compile.----I get the same error. Hope someone else knows why the linker can't find these symbols.----Not to get off topic, but I'm wondering if Apple will have some kind of a program where you can send Apple software disks back to them, and they will replace them with Universal Binary builds.----Try building without ZeroLink. It worked for me.----Well I got a sample project to compile, and I set the Target Configuration properly, but I don't see a i386 binary in the package. Must still be missing something...----AAhhh... it's not a separate file. Checking in the Terminal with the file command gives:
file testtest: Mach-O fat file with 2 architecturestest (for architecture ppc): Mach-O executable ppctest (for architecture i386): Mach-O executable i386One other thing, the directions talk about "Development" and "Release" build configurations. Existing projects that are converted to Xcode 2.1 format have "Development" and "Deployment" configurations. For what it's worth...In my existing app test, I was getting a warning about having Prebinding turned on, but for some reason it went away - not sure what the problem was.----So-called "universal" binaries are regular Mach-O Fat binaries that contain code for the i386 architecture, just like we've always done with fat ppc/ppc64 binaries.----I'm a little confused then. Do Universal Binaries contains raw x86 and PPC assembly? I want to know more about the file format...it doesn't make sense how they can work on PPC and x86 "natively".My guess (it is a guess - I know nothing about assembly-level stuff) is that since it's a "Mach-O binary" with a copy of the program in PPC and x86 code, Mach knows how to find the entry point for whichever architecture it's running on and ignores the other.Yes, basically Mach-O can contain several sections on a per-architecture basis. When loading an executable, the system will search for a section that corresponds to the current CPU architecture. This is already done with PPC for 32/64-bit fat executables, because PPC32 is not compatible with PPC64, and they have to be stored separately.----So, for Mac OS 10.4, is
/usr/bin/file the only way to determine if a file is built for Intel or PPC?Maybe it (architecture displayed in Get Info) will be in the 10.4.1 or 10.4.2 update.you can use lipo -detailed_info too----
Ok I'm trying to compile the CURLHandle framework as a universal binary, but it links against libcrypto, libssl, libc, and libz. Do I leave these how they are, or do I link against the ones in MacOSX10.4u.sdk? Basically, can a universal binary link against a non-universal binary anything (bundle, framework, dylib, etc)?
- You should set it to link against the ones in the universal SDK by choosing that as a target - this will work, trying to link against non-fat libraries won't. To use the source presently available for CURLHandle, you need to upgrade the target, set it to universal, remove the script which tries to link to the static library, and remove the reference to the static curl library in the Other Linker Flags setting (in build settings). After that it should work.
- Processes are all-or-nothing. That is, a single application must contain exclusively PPC code or exclusively x86 code, you can't mix and match. All of your framework's dependencies must be met with libraries for each architecture.
Mac OS 10.4.3 now allows you to view the architecture for an application in the Get Info window; the architectures are also displayed in the browser view file pane.
I found a gotcha with converting projects to Universal Binaries. I noticed something tonight when I first tried to build an app that i have been working on as a Universal Binaries. I have 2 frameworks that I have written, that are both compiled as Universal Binaries. I have used them in another universal app with no problems, However, that app was universal before i imported the frameworks. On the app i am working on now, when i tried to build, it basically broke the frameworks. I had to remove the frameworks from my project and import them again to get the project to build. After that it has been smooth sailing.
Anyone know how to detect PPC-vs-x86 during compilation? I want something like this:
- if [compiling for PPC]
typedef long myType ;
typedef char myType ;
Then when I compile a Universal Binary, it will use one definition when compiling the PPC code, and the other when compiling the Intel code.
Muchos gracias, --Darel DarelRex@gmail.com
First of all, Apple suggests that you don't test this directly. If you needed big endian vs. little endian, you'd use the
__LITTLE_ENDIAN__ macros. If you need to use a variable of a certain size, use NSInteger/NSUInteger...or an explicitly sized type like uint32_t. If you need to know pointer size for some reason, you can use the
__LP64__ macro (not quite the same thing but similar). But finally, if you really need conditional branching, you can use
Also, may I ask why you need two different data types depending on endianness? That's awfully weird and sounds like you may be doing something else in a non-standard fashion, although of course I could just be suffering from a failure of imagination. -- MikeAsh