according to apple's mac processor list a i5 should be a 64 bit processor. According to this video if i type uname -m in terminal i should get x86_64. but in my case it says i386 instead. why is that? i developed also an app, that is a 64 bit only app. that app is NOT running on this mac. it crashes at start. but if i compile in x86_64 mode instead of 64 bit only then it works. does somebody have an idea on how to fix this?
ARC is not supported under 32-bit runtimes. Therefore if you are using ARC you will need to produce 64-bit binaries only.
From Transitioning to ARC Release Notes:
ARC is supported in Xcode 4.2 for OS X v10.6 and v10.7 (64-bit
applications) and for iOS 4 and iOS 5. Weak references are not
supported in OS X v10.6 and iOS 4.
The video is wrong: uname -m tells you what mode the kernel is running in, which has very little to do with userland programs such as yours. If you want to to find out for sure if the CPU is 64-bit capable, use sysctl hw.cpu64bit_capable -- since you have an i5, it should print hw.cpu64bit_capable: 1 meaning "yes" (0 would mean "no"). Also, run the Activity Monitor utility, and note the modes various processes are running in -- my guess is that a lot will be in "Intel (64 bit)", since in 10.6 most of the programs supplied with OS X came in 32/64-bit dual architecture, and will prefer 64-bit.
Now, about your app: It should run in 64-bit mode whether you compile it 64-bit only or 63/64, so I doubt that's the problem. To be sure, compile it 32/64, run it, then use Activity Monitor to see what mode it's actually running in.
I can't tell for sure, but my guess would be that your app has a problem with ARC. At least as I understand it, that's only enabled if you compile 64-bit only (and disabled if you compile 32/64).
Related
Hi everyone :) am a newbie to develop applications for Mac. My questions are regading to different OS architectures in Mac and am greatly confused in this. Kindly bear with me if my questions are very cheap. Thank u all:)
I know that there is 32 bit support for 10.6(SnowLeopard). I would like to know if there is 32 bit support for 10.7(Lion)??
I have a 64 bit machine. I want a 32 bit 10.7 on it. How would i do so??
I have a 32 bit iMac and I have 10.6.8 in it. I have built an application on it; the application uses a user developed library which is also 32 bit. Now I carry on this application to another Mac machine which has 64 bit processor with 10.7(Lion). Will I be able to execute the same application as such in 10.7(Lion)?? I was not able to do so.
OS X uses a binary format that can support multiple architectures (e.g. 32- and 64-bit Intel, as well as PowerPC, etc) in a single executable or library. Most of the binaries and libraries in Lion are dual-architecture 32&64-bit Intel. So, yes, there is 32-bit support in Lion.
There is no such thing as 32-bit Lion; it's a dual-architecture OS. It can boot the kernel in either 32- or 64-bit mode, and run programs in 32- or 64-bit mode. Unlike most other OSes, it can even run programs in 64-bit mode under a 32-bit kernel. Whenever you run a program in Lion, it checks what architectures the program includes and what the CPU is capable of, and picks the "best" mode to run that program in.
There's no obvious reason this shouldn't work. If you were trying to use a 32-bit-only library from a program that was running in 64-bit mode, or a 64-bit-only library from a program running in 32-bit, it would fail. But if the program is 32-bit only it'll obviously run in that mode, your user developed library is 32-bit, and all of the libraries supplied with the OS are 32+64-bit.
There are a few things that might cause your 32-bit program to fail under Lion. First, does it depend on any libraries other than the one you mentioned and those supplied with the OS (e.g. libraries compiled locally by something like MacPorts, Fink, or Homebrew)? If so, those libraries might've been compiled 64-bit only. IMO libraries should always be compiled for all relevant architectures to avoid this sort of problem, but that's not the default.
Another possible source of trouble is if your program isn't really a program, but something that loads into another program (e.g. a plugin of some sort, screensaver, etc). In that case, your plugin needs to support whatever mode the program that'll load it is running in. You can actually get this issue with Java programs, since the java runtime will start in 64-bit mode (when the CPU supports it) in Lion.
Telling us more about your program and what specific error you get would probably help a lot...
I want to compile CUDA code on mac but make it executable on Windows.
Is there a way to set up an nvcc CUDA cross compiler?
The problem is that my desktop windows will be inaccessible for a while due to traveling, however i do not want to wasted time by waiting til i get back and compile the code. If I have to wait then it would be a waste of time to debug the code and make sure it compiles correct and the likes. My mac is not equipped with cuda capable hardware though.
The short answer, is no, it is not possible.
It is a common misconception, but nvcc isn't actually a compiler. It is a compiler driver, and it relies heavily on the host C++ compiler in order to steer compilation both host and device code. To compile CUDA for Windows, you must using the Microsoft C++ compiler. That compiler can't be run on Linux or OS X, so cross compilation to a Windows target is not possible unless you are doing the compilation on a Windows host (so 32/64 bit cross compilation is possible, for example).
The other two CUDA platforms are equally incompatible, despite requiring gcc for compilation, because the back ends are different (Linux is an elf platform, OS X is a mach platform), so even cross compilation between OS X and Linux isn't possible.
You have two choices if compilation on the OS X platform is the goal
Install the OS X toolkit. Even though your hardware doesn't have a compatible GPU, you can still install the toolkit and compile code.
Install the Windows toolkit and visual studio inside a virtual windows installation (or a physical boot camp installation), and compile code inside Windows on the Mac. Again, you don't need NVIDIA compatible hardware to do this.
If you want to run code without a CUDA GPU, there is a non-commercial (GPU Ocelot) and commercial (PGI CUDA-x86) option you could investigate.
I made a cross compiling toolchain for arm-gcc, configuring binutils, newlib, gcc and gdb for the arm-elf target. The problem I am having is, when I compile a program with arm-elf-gcc on my Mac, it generates a 32 bit executable with cannot be executed in the 64 bit environment.
What is the easiest way to circumvent this? I could place the 32 bit executables to an arm environment, but I am interested to know if I could execute the file in my Mac in any way?
--Added--
I should have done this before, but let me inform that the target of my program is a Beagleboard, and I was expecting that I would compile and generate the objects using arm-gcc on my Mac OS X and transfer the *.o to the Beagleboard to view output. Alas, it gives the same error on the Beagleboard as well when I do a ./hello.o.
Thanks,
Sayan
There are several issues preventing you from running your executable on a Mac.
1) Architecture. Your Mac is probably an x86/x86_64 machine (or PowerPC) but your binary is compiled for ARM architecture (which is the whole point of using a cross-compiler). These instruction sets are not compatible.
2) Your binary is linked as an ELF object file, whereas Macs use the Mach-O object file format. Your OS cannot load this executable format.
3) Your executable is linked against newlib (for some target which is probably not Mac OS) instead of the Mac OS libc. Your system calls are not correct for this platform.
If your program is a standard unix executable, you may be able to simply compile it with the standard system gcc and it will run. Otherwise, you can run it in an ARM emulator, though this may be pretty complicated to set up.
The fact that it's 32-bit is irrelevant - you can't execute ARM code on a Mac (unless you can find some kind of ARM emulator).
My development machine has a 64 bit proc, running a 32 bit distribution.
I would like to compile and test a kernel module with a 64 bit kernel. My question is :
Is there a 64 bit liveCD with kernel development package included ?
If it does not exist, How can I build a module for a 64 bit kernel ? Then I can eventually test it with a liveCD
You can install a 64-bit VM on a 32-bit operating system, provided the CPU supports it. I know this is possible with VMWare, don't know about anything else.
If you're doing any system development nowadays, I'd say use a VM, regardless of the target platform. Just use a VM.
It might be more technical than you would want to try, but, if you can get a 64bit toolchain installed, you should be able to compile the kernel through:
make ARCH=amd64 CROSS_COMPILE=x86_64-pc-linux-gnu- menuconfig
You should be able to boot your regular 32bit userland with a 64bit kernel (if you select the appropriate binary compatibility options)
Cheers!
http://www.ubuntu.com/desktop/get-ubuntu/download has links for 64-bit download, and the "make USB on windows" option includes screenshots showing how to make a bootable 64-bit ubuntu USB memory stick. (None of the other options in the {CD, USB} x {Windows, Mac, Ubuntu} instructions mention anything about only working for x86 vs x86-64.)
I initially thought that 64 bit instructions would not work on OS-X 10.5.
I wrote a little test program and compiled it with GCC -m64.
I used long long for my 64 bit integers.
The assembly instructions used look like they are 64 bit. eg. imultq and movq 8(%rbp),%rax.
I seems to work.
I am only using printf to display the 64 bit values using %lld.
Is this the expected behaviour?
Are there any gotcha's that would cause this to fail?
Am I allowed to ask multiple questions in a question?
Does this work on other OS's?
Just to make this completely clear, here is the situation for 32- and 64-bit executables on OS X:
Both 32- and 64-bit user space executables can be run on both 32- and 64-bit kernels in OS X 10.6, without emulation. On 10.4 and 10.5, both 32- and 64-bit executables can run on the 32-bit kernel. (This is not true on Windows)
The user space system libraries and frameworks are built 32/64-bit fat on 10.5 and 10.6. You can link against them normally, whether you're building for 32-bit, 64-bit, or both. A few libraries (basically the POSIX layer) are also built 32/64-bit fat on 10.4, but many of them are not.
On 10.6, the build tools produce 64-bit executables by default. On 10.5 and earlier, the default is 32-bit.
On 10.6, executables that are built fat will run the 64-bit side by default. On 10.5 and earlier, the 32-bit side is executed by default.
You can always manually specify which slice of a fat executable to use by using the arch command. eg. arch -arch i386 someCommandToRunThatIWantToRunIn32BitMode. For application bundles, you can either launch them from the command line, or there is a preference if you "get info" on the application.
OS X and Linux use the LP64 model for 64-bit executables. Pointers and long are 64 bits wide, int is still 32 bits, and long long is still 64 bits. (Windows uses the LLP64 model instead -- long is 32 bits wide in 64 bit Windows).
Mac OS X 10.5 supports 64-bit user-land applications pretty well. In fact, Xcode runs in 64-bit in 10.5 on a compatible architecture.
It's only the built-in applications (Finder, Safari, frameworks, daemons etc.) also have the 64-bit version in 10.6.
Meta: I don't like to see answers deleted. I guess this has been discussed somewhere.
Anyway, KennyTM and the other kind sole got me started and although one answer was deleted, I appreciated your efforts.
It looks like this is expected behaviour on the Mac, and it even seems to work on a 32-bit Linux as well (although I have not tested extensively)
Yep. GCC behaves different (at least in my limited observation) for 32 (-m32) and 64 (-m64) bit modes. In 32 bit, I was able to access variable arguments using an array. In 64 bit mode this just does not work.
I have learnt that you MUST access variable parameters using va_list as defined by stdarg.h because it works in both modes.
Now I have a command-line program that runs and passes all of my test cases in 32 bit and 64 bit modes on Mac OS-X.
The program implements a linked list garbage collector sweeping 16-byte aligned malloc-allocated objects from a global list as well as machine registers and the stack - actually, there are extra registers in 64 bit mode, so I still have a bit of work to do.
Objects are either a collection of 32 or 64 bit words which link together to form LISP/Scheme-like data structures.
In summary, it is a complex program that does a lot of messing with pointers and it works the same under 32 and 64 bit modes.
Asking multiple questions does not get you all the answers you might want.
It seems to work, as I wrote, on Linux.
Again, thank you for helping me with this.