I know this seems ridiculous but I am worried about spending hours on a project and finding that it doesn't work.

I want to start learning C++ to make applications for my Raspberry Pi 2. Simple enough question: if I compile code on a 64 bit PC, will it work on the Pi? Sort of like how Java runs in everything with no problems.

Thanks, and I don't mind if this is tagged as duplicate as long as I get answered. :)

EDIT: If I write code on a PC, can it compile on a Pi if the above doesn't work?


if I compile code on a 64 bit PC, will it work on the Pi?

No -- as per other answers, C++ is a purely compiled language, meaning it goes straight from source to machine code, which is architecture specific. Or it might be more accurate to say once compiled into an executable that executable is stored as machine code; when it is compiled I believe it generally passes through intermediate steps, the most significant of which would be C -> assembly (which is architecture specific) -> machine code. Assembly is more-or-less a human readable form of machine code (but can't be directly executed).

Sort of like how Java runs in everything

This is because java is compiled to bytecode (e.g., .class files), which is interpreter specific. The interpreters themselves are executable machine code and as such not portable; i.e., the JRE from an x86_64 PC could not be used on a Pi. However, java code written and compiled on the PC could be run on the Pi by its java interpreter.

So compiled java bytecode is executed by an interpreter which is executed by the CPU, which is why the compiled bytecode is portable. Machine code is executed directly by the CPU, and as such must be created specifically for the style of CPU it is to be executed on.

If I write code on a PC, can it compile on a Pi

Yes, but there is a caveat to this.

C++ is a very portable language, but as just explained, it must be compiled into a very unportable form before it can be useful. The caveat is that there are some things which are not standardized in C or C++, and these are "platform dependence" issues. In this context "platform" refers more or less to two fundamental elements of the operating system, the kernel and the native C library, upon which the C++ library depends. The relationship between these two things is very intimate due to the nature of system calls. There are a wide range of things programs are dependent on the kernel to do for them; the primary role of the kernel is to coordinate such activities. These are things which involve peripheral hardware, i.e., anything beyond the CPU and main memory (including the keyboard, the display, storage, etc). Further, on contemporary multi-tasking OS's the kernel also controls when and for how long process code gets to run on the CPU. So again, a very high degree of intimate cooperation is involved.

There are at least two significant, fundamental areas that "standard C" does not cover here:

  • Low level filesystem access.

  • Networking

The former is largely made up for by the fact that there is standardized access to files via the file stream interface. However, note this does not include reading directories!

The second one, networking, simply isn't covered at all, although some aspects of actual networking may use stream interfaces that are identical to those used to access files. However, neither standard C nor C++ includes basic functions required to, e.g., create/open a network socket and make an inet connection.

Those things are dealt with in platform specific libraries, meaning they vary not from processor to processor but from operating system to operating system, or categories/families of such. The operating system predominantly used on the Pi is GNU/Linux (where the kernel is linux, and the native libraries are from GNU); Raspbian is a form of this (sometimes different forms of GNU/Linux are referred to as individual operating systems, e.g., Raspbian, Ubuntu, etc., but in this context they are all identical to one another).

GNU/Linux is regarded as mostly POSIX compliant. This is the largest group of operating systems in the computing world, and includes various direct UNIX decedents such as Solaris, early offshoots such as BSD, later offshoots such as linux, and OSX. POSIX does include standardization for networking and filesystem access in C, so if you are writing networking code for use on Raspbian or linux generally it can be done following POSIX standards.

However, the operating system used predominantly on PCs, Microsoft Windows, is not a POSIX compliant operating system and has its own customized libraries for things such as networking.

So that's the one thing to beware of: If you are writing networking code in C++ on a Windows PC, it will not be portable to a Linux powered Pi. There are cross-platform networking libraries available for C++, however (I believe boost should have this well covered), which will allow you to get around that. On the other hand, if you are using Linux on your PC and don't plan to port your code to Windows then you can use standard linux/POSIX methodologies and it will compile and run fine on any linux based device regardless of architecture.

Well, ideally it will. Porting code from one architecture to another is a classic and I think commonplace way to discover bugs in your code that you did not know existed. This is because a particular compiler on a particular platform and architecture may, e.g., arrange things in a way that is forgiving of a small buffer overrun. This is a sort of luck which can be become bad when that code is compiled elsewhere, and by coincidence the arrangement is not so forgiving and suddenly something that has run fine for years blows up in your face.

Fixing those things is the same as fixing them when they don't work in the first place, although it may be particularly tedious and irritating if it is something large and complex which was built up over time and the flaw was incorporated early on. Of course, if it is all appropriately compartmentalized and you have basic tests for the components, you can hopefully pin the issue down using those tests, and once the code is fixed it will run fine in both contexts.

  • Thank you for your answer. I won't do TL;DR because I actually read the whole thing :) – tycrek Jul 2 '16 at 14:25

Normally when you compile in C++ you do so by selecting a specific hardware target such as x86 or x64 if you're using a PC (intel CPU architecture). Raspberry PI has a different CPU architecture called ARM, so normally a program compiled for one platform does not run on another. Yet if you have the source code you could find a suitable ARM C++ compiler and make an executable that runs on the raspberry pi. Just try to make sure your C++ code is platform independent eg ANSI C++ and try to avoid using IDE specific C++ versions such as Visual C++ from Microsoft Visual Studio. Something that could be interesting is using QT. I know that with this IDE you're capable of switching compile platforms by just selecting a different option in a drop down list. I have tested x86 and ARM abiV7 (for android). I don't know if raspberry Pi could be among the possible options


Of course you can compile for the Pi on a PC. You install the Pi library .h header filles and a toolchain that does cross-compiling.

You can even modify the kernel here: https://www.raspberrypi.org/documentation/linux

EDIT: C was invented to be complied on a on a foreign machine to write the Unix os . There are no input or output statements in the C language. All I/O is done with a machine dependant library. The size of number types also changes for different machines. To write portable code, make no assumptions about the size of int or pointers, for example. If you as old as I and remember the history, saying you can't compile pi code on a PC is kind of absurd.


Current supported raspbian is 32bit. Very likely you will have issues with any 64bit code unless you have 32bit processor checks.

See this for more info: Raspberry Pi 3 and 64-bit kernel, differences between armv7 and armv8

  • 1
    Further, neither 32 bit nor 64 bit x86 (Intel, AMD) machine code will run on any form of ARM and vice versa. So it is not just about 32 vs 64 bit. – goldilocks Jul 2 '16 at 12:37
  • It depends on the codebase and how cross compatible it is. Currently we have an Everquest emulator for Linux/Winblows that compiles and runs minus 2 crash issues. But for the most part yes you are correct. – Dan V Jul 2 '16 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.