2

I am developing a cross-platform application and I need to determine whether machine B will be able to run the application that is compiled on machine A.

I am using Qt and I already understand that I need to either package the Qt libraries with the application or statically link against Qt itself.

I also understand that something compiled on Windows can't run on Linux.

However, there are still some other vectors that I'm not sure to what extent they matter. Here is the summary of my current understanding:

Affects Portability

  • Operating System (Windows, Mac, Linux)
  • Availability of third party libraries (Qt, static vs dynamic linking, etc)

May Affect Portability

  • Flavor of Linux (Ubuntu, Red Hat, Fedora)
  • Architecture (32 or 64-bit)
  • Version of Operating System (Windows 7 vs Windows XP, Rhel5 vs Rhel6)
  • Instruction type (i386, x64)

Of the May Affect Portability items, which ones actually do? Are there any that I am missing?

Cory Klein
  • 51,188
  • 43
  • 183
  • 243
  • Things like WINE and MONO muddy the water here – Mooing Duck Jul 12 '13 at 16:59
  • There are two extremes to this question. The minimal quantum of commonality is when exactly one executable exists which runs on both systems; the other is when every program which runs on one computer will also run on the other. Portability is not a binary property. – MSalters Jul 12 '13 at 18:06

4 Answers4

2

All. At least potentially.

If two different machines have no binary compatibility (e.g. they run on different architectures, or interface to incompatible systems), then it will be impossible to create a single binary that will run on both. (Or... does running a Windows program under Wine on Linux count?)

Otherwise, it depends. You mention third party libraries: if they're dynamically loaded, they have to be there, but there's always static linking, and there may be ways of deploying with the dynamic library, so that it will be there.

The 32 bit vs. 64 bit is a difference in architectures: a 32 bit program will not run in a 64 bit environment and vice versa. But most modern systems will make both environments available if they are on a 64 bit machine.

Issues like the flavor and version of the OS are more complex. If you use any functions recently added to the OS, of course, you won't be able to run on machines with an OS from before they were added. Otherwise: the main reason why the low level system libraries are dynamically loaded is to support forwards and backwards compatibility; I've heard that it doesn't always work, but I suspect that any problems involve some of the rarer functions. (There are limits to this. Modern Windows programs will not run under Windows95, and vice versa.)

There is also an issue as to whether various optional packages are installed. Qt requires X Windows under Linux or Solaris; I've worked on a lot of Linux and Solaris boxes where it wasn't installed (and where there wasn't even a display device).

And there is the issue whether it will run acceptably. It may run on a smaller, older machine than the one on which you tested it, but it could end up paging like crazy, to the point where it becomes unusable.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
0

If you compile an application on a 64-bit processor, it wouldn't by default run on a 32-bit processor. However, you can pass options to the compiler to have it compile code to run on a 32-bit processor. For example, if you're using GCC on a 64-bit machine, if you pass -m32, it will compile 32-bit code. 32-bit code by default can run on a 64-bit machine.

Sources

https://stackoverflow.com/a/3501880/193973

Community
  • 1
  • 1
Sam Cantrell
  • 585
  • 6
  • 19
0

Different flavors of Linux or versions of operating systems may have different system libraries. For example, the GetModuleFileNameEx function is only available in Windows XP and up. As long as you watch what functions you use though, it shouldn't be too much of a problem.

The x64 architecture is backwards compatible with x86 ("32-bit"), so programs compiled for the x86 will run on x64 machines, but not vice versa. Note that there are other, less common architectures too, such as the ARM and PowerPC.

Colonel Thirty Two
  • 23,953
  • 8
  • 45
  • 85
0

I can immediately think of three things that interfere with portability. But if your code is in a file format understood by both systems, an instruction set understood by both systems, and only makes system calls understood by both systems, then your code should probably run on both systems.

  • Executable File format
    • Windows understands PE, COFF, COM, PEF, .NET, and others
    • Linux by default ELF, OUT, and others
    • MaxOSX uses Mach-O
    • Linux has extensions to run the Windows/Mac formats too (Wine, Mono...)
  • Instruction set
    • Each processor is a little different, but
    • There is usually a "lowest common denominator" which can be targetted
      • Sometimes compilers will write code to do a function twice
      • one with the LCD set, one with a "faster" instruction set
      • and the code will pick the right one at runtime.
    • x64 can run 64bit and 32bit, but not 16bit.
    • x86 can run 32bit and 16bit, but no 64bit.
  • Operating System calls
    • Each OS usually has different calls
    • This can be avoided by using a dynamic library, instead of direct OS calls
      • Such as... the C runtime library.
      • Or the CLR for .Net.
Mooing Duck
  • 64,318
  • 19
  • 100
  • 158