CocoaDev

Edit AllPages

[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 General/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, General/PowerPC, or both Intel and General/PowerPC.http://developer.apple.com/documentation/General/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. General/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 General/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 General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSCreateObjectFileImageFromFile referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSGetSectionDataInObjectFileImage referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSHasModInitObjectFileImage referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSInstallLinkEditErrorHandlers referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSLinkModule referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSLookupAndBindSymbol referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSSymbolDefinitionCountInObjectFileImage referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSSymbolDefinitionNameInObjectFileImage referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib___sF referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_get_image_header referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_get_image_name referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_image_count referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib__dyld_register_func_for_add_image referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_abort referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_fprintf referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_getenv referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_getsectbynamefromheader referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_malloc referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcat referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcmp referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_strcpy referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSAddressOfSymbol referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSFindSectionAndOffsetInObjectFileImage referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_NSIsSymbolNameDefined referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_fwrite referenced from General/ZeroLink expected to be defined in /usr/lib/libSystem.B.dylib_calloc referenced from General/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 General/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…—-General/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 General/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)?


Update

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 ; #else typedef char myType ; #endif

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 General/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 BIG_ENDIAN and LITTLE_ENDIAN macros. If you need to use a variable of a certain size, use General/NSInteger/General/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 ppc and i386. –General/JediKnil —- Thanks, General/JediKnil! Very helpful. – General/DarelRex@gmail.com


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. – General/MikeAsh