32bit64bitarmlinux
I'm curious. Is it possible to install a 64 bit program on a 32 bit OS with a 64 bit processor?
I'm running Linux on a raspberry pi 3 and I try to install a newer version of MongoDB:
armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
lscpu is telling you that your architecture is i686 (an Intel 32-bit CPU), and that your CPU supports both 32-bit and 64-bit operating modes. You won't be able to install x64 built applications since they're built specifically for x64 architectures.
Your particular CPU can handle either the i386 or i686 built packages. There are a number of ways to verify your architecture & OS preferences.
As you're already aware, you can use the command lscpu. It works well at giving you a rough idea of what you're CPU is capable of.
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 4
Thread(s) per core: 2
Core(s) per socket: 2
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 37
Stepping: 5
CPU MHz: 1199.000
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
NUMA node0 CPU(s): 0-3
This is actually the data provided by the kernel that most of the tools such as lscpu use to display. I find this output a little nice in the fact that it shows you some model number info about your particular CPU. Also it will show you a section for each core that your CPU may have.
Here's output for a single core:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
stepping : 5
cpu MHz : 1466.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
bogomips : 5319.74
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Here's what the first 3 lines of each section for a core looks like:
$ grep processor -A 3 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
--
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
--
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
--
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
The output from /proc/cpuinfo can also tell you the type of architecture your CPU is providing through the various flags that it shows. Notice these lines from the above command:
$ grep /proc/cpuinfo | head -1
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
The flags that end in _lm tell you that your processor support "long mode". Long mode is another name for 64-bit.
This command can be used to determine what platform your kernel was built to support. For example:
64-bit kernel
$ uname -a
Linux grinchy 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
32-bit kernel
$ uname -a
Linux skinner.bubba.net 2.6.18-238.19.1.el5.centos.plus #1 SMP Mon Jul 18 10:07:01 EDT 2011 i686 i686 i386 GNU/Linux
This output can be refined a bit further using the switches, [-m|--machine], [-p|--processor], and [-i|--hardware-platform].
Here's that output for the same above systems.
64-bit
$ uname -m; uname -p; uname -i
x86_64
x86_64
x86_64
32-bit
$ uname -m; uname -p; uname -i
i686
i686
i386
NOTE: There's also a short-form version of uname -m that you can run as a stand alone command, arch. It returns exactly the same thing as uname -m. You can read more about the arch command in the coreutils documentation.
excerpt
arch prints the machine hardware name, and is equivalent to ‘uname -m’.
Probably the best tool for analyzing your hardware has got to be hwinfo. This package can show you pretty much anything that you'd want/need to know about any of your hardware, right from the terminal. It's save me dozens of times when I'd need some info off of a chip on a system's motherboard or needed to know the revision of a board in a PCI slot.
You can query it against the different subsystems of a computer. In our case we'll be looking at the cpu subsystem.
$ hwinfo --cpu
01: None 00.0: 10103 CPU
[Created at cpu.301]
Unique ID: rdCR.a2KaNXABdY4
Hardware Class: cpu
Arch: X86-64
Vendor: "GenuineIntel"
Model: 6.37.5 "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz"
Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,xtopology,nonstop_tsc,aperfmperf,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,sse4_2,popcnt,aes,lahf_lm,ida,arat,tpr_shadow,vnmi,flexpriority,ept,vpid
Clock: 2666 MHz
BogoMips: 5319.74
Cache: 3072 kb
Units/Processor: 16
Config Status: cfg=new, avail=yes, need=no, active=unknown
Again, similar to /proc/cpuinfo this command shows you the makeup of each individual core in a multi-core system. Here's the first line from each section of a core, just to give you an idea.
$ hwinfo --cpu | grep CPU
01: None 00.0: 10103 CPU
Model: 6.37.5 "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz"
02: None 01.0: 10103 CPU
Model: 6.37.5 "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz"
03: None 02.0: 10103 CPU
Model: 6.37.5 "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz"
04: None 03.0: 10103 CPU
Model: 6.37.5 "Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz"
This is probably the most obvious way to tell what architecture your CPU is presenting to the OS. Making use of getconf, your querying the system variable LONG_BIT. This isn't an environment variable.
# 64-bit system
$ getconf LONG_BIT
64
# 32-bit system
$ getconf LONG_BIT
32
Yet another tool, similar in capabilities to hwinfo. You can query pretty much anything you want to know about the underlying hardware. For example:
# 64-bit Kernel
$ lshw -class cpu
*-cpu
description: CPU
product: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
vendor: Intel Corp.
physical id: 6
bus info: cpu@0
version: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz
slot: None
size: 1199MHz
capacity: 1199MHz
width: 64 bits
clock: 133MHz
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid cpufreq
configuration: cores=2 enabledcores=2 threads=4
# 32-bit Kernel
$ lshw -class cpu
*-cpu:0
description: CPU
product: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz
vendor: Intel Corp.
physical id: 400
bus info: cpu@0
version: 6.15.2
serial: 0000-06F2-0000-0000-0000-0000
slot: Microprocessor
size: 1800MHz
width: 64 bits
clock: 800MHz
capabilities: boot fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe x86-64 constant_tsc pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm
configuration: id=1
*-logicalcpu:0
description: Logical CPU
physical id: 1.1
width: 64 bits
capabilities: logical
*-logicalcpu:1
description: Logical CPU
physical id: 1.2
width: 64 bits
capabilities: logical
Several of the commands report that what looks to be a 32-bit CPU as supporting 32-bit & 64-bit modes. This can be a little confusing and misleading, but if you understand the history of CPU's, Intel specifically, you'll know that they have a history of playing games with their products where a CPU might have an instruction set that supports 16-bits, but can address more RAM that 2^16.
The same thing is going on with these CPUs. Most people know that a 32-bit CPU can address only 2^32 = 4GB of RAM. But there are versions of CPUs that can address more. These CPUs would often make use of a Linux kernel with the suffix PAE - Physical Address Extension. Using a PAE enabled kernel along with this hardware would allow you to address up to 64GB on a 32-bit system.
You might think well then why do I need a 64-bit architecture? The problem with these CPUs is that a single processes space is limited to 2^32, so if you have a large simulation or computational program that needed more than the 2^32 of addressable space in RAM, then this wouldn't have helped you with that.
Take a look at the wikipedia page on the P6 microarchitecture (i686) for more info.
In general it can get confusing because a number of the commands and methodologies above are using the term "architecture" loosely. If you're interested in whether the underlying OS is 32-bit or 64-bit use these commands:
If on the other hand you want to know the CPU's architecture use these commands:
Specifically you want to look for fields where it says things like "width: 64" or "width: 32" if you're using a tool like lshw, or look for the flags:
lm: Long Mode (x86-64: amd64, also known as Intel 64, i.e. 64-bit capable)lahf_lm: LAHF/SAHF in long modeThe presents of these 2 flags tells you that the CPU is 64-bit. Their absences tells you that it's 32-bit.
See these URLs for additional information on the CPU flags.
man pages
articles:
TL,DR: if you're only offered a choice of “32-bit” and “64-bit”, neither is right for a Raspberry Pi (or any other ARM-based computer). You need a package for ARM, and the right one to boot, which is armhf.
“32-bit” and “64-bit” are only one of the characteristics of a processor architecture. Many processor families come in both 32-bit and 64-bit variants (x86, ARM, Sparc, PPC, MIPS, …). Debian alone has 23 official binary distributions for different processor characteristics and different software characteristics.
You need to install a package which matches the ABI for your system. The ABI (application binary interface) includes the processor type (more precisely, its instruction set), but also other characteristics related to the ways programs interact. In particular, when a program makes a call to code that is in a library, the ABI determines how the arguments to the library function are passed (in registers or on the stack).
In the PC world, there are two instruction sets (up to minor variations that do not matter):
Both Intel and AMD make processors that implement the x86 and x86-64 instruction sets. Modern PCs have processors that support both the x86-64 and the x86 instruction sets; older PCs have processors that support only x86. Because the x86 instruction set uses 32-bit registers and the x86-64 instruction set uses 64-bit registers, and because for each instruction set there is a single ABI used by all Linux installations¹, these are often described as just “32-bit” or “64-bit”. In a PC context, “32-bit” means “x86” and “64-bit” means “x86-64”.
ARM processors have a completely different instruction set. You cannot install an x86 or x86-64 package on an ARM system. You need a package for ARM, for the correct instruction set, and more generally for the correct ABI. There are no major 64-bit distributions for 64-bit ARM processors yet, because the ARMv8 architecture revision which introduces a 64-bit instruction set is still very new and not commonly available. There are however multiple 32-bit ABIs, which assume the existence of different processor features and use different versions of the argument-passing convention. The main ARM ABIs used on Linux are:
All devices that support armhf also support armel; however a given system installation must be consistent. Raspbian uses armhf (in fact, it started out as a port of Debian's armel to armhf, back when armhf was a new thing).
¹ At least for mainstream distributions. There are embedded distributions that have several x86 binary releases, with packages compiled against different versions of the standard C library (glibc, dietlibc, uclibc, …).
Best Answer
In principle yes, but the processor and the OS have to support it.
On ARMv8, a 32-bit (Aarch32) kernel cannot run 64-bit (Aarch64) processes. This is a limitation of the processor.
There are other processors that don't have this limitation, for example it is possible to run x86_64 processes on top of an x86_32 kernel on an x86_64 processor, but few kernels support it, presumably because it's of limited utility (mostly, you save a bit of RAM in the kernel by making it 32-bit). Linux doesn't support it, but Solaris does.
You can keep your existing 32-bit OS if you run a 64-bit kernel. An Aarch64 Linux kernel can run Aarch32 processes. Raspbian doesn't support this out of the box, so you'd need to maintain both a 32-bit OS and a 64-bit OS. You can use either one as the main OS (i.e. the one that runs init and system services) and the other to run a specific program using chroot. See How do I run 32-bit programs on a 64-bit Debian/Ubuntu? for a practical approach.
Note that you will need to install all the libraries that the 64-bit program requires. Any given process must be either wholly 32-bit or wholly 64-bit, so you can't use a 32-bit library in a 64-bit executable.
Unless you have strong reasons to keep a 32-bit system, if you need to run a 64-bit executable, it would be easier to install a 64-bit system.
Note that the only thing that 64-bit programs can do but 32-bit programs can't is address more than about 3GB of virtual memory, which is of limited utility on a system with 1GB of RAM. You may get performance benefits from the extra, larger registers, but you'll also lose performance from the extra memory accesses.