Shouldn't one build run in different machines?

[portilhe]

This may well be a silly question, but I was under the impression that if I build my application in one Linux machine, the built binary would run in a different Linux machine... Am I wrong?

The application is a simple one, doesn't use any special drivers or anything. It's just a simple game. The only possible explanation I can come up with is that one of my machines is 64 bit and the other one is 32 bit. Other wise they are both running the same distribution of linux. Could this be an issue?

I'm at a loss here.

-Manu

[ChrisW67]

This may well be a silly question, but I was under the impression that if I build my application in one Linux machine, the built binary would run in a different Linux machine... Am I wrong?

Not entirely correct. Provided all the required dependencies, Qt or other, are on the target machine then this will typically be true. If you move a 32-bit program to a 64-bit machine then all the necessary 32-bit dependencies will need to be present, and this may not be the case out-of-the-box.

If you have an app failing on the 64-bit machine try running:

$ ldd my_program_exe

$ ldd my_program_exe

To copy to clipboard, switch view to plain text mode 

to see if the obvious dependencies are present.

[conner686]

In short, no. In long, maybe. The OS provides libraries, and launches the executable. The processor still has to know how to actually run it. As an extreme example, the prebuilt QT bundle for OSX is built for Intel-based Macs. Even with an appropriate version of OSX installed, my PPC box can't run them. I get to build from source.

[portilhe]

It goes in the other direction. I compiled it on my 64 bit and it's not running on the 32 bit one. However, as I mentioned, it's a very simple program, I don't think I am making it depend on very sufisticated stuff. I am using QtGui, QDialog, QMainWindow, QWidget, QTimer and a few other ones... but I don't think I am using anything machine dependent.

I realise that maybe I didn't clearly explain everything. I have Qt installed in my 64bit machine where I compiled the program. Do I need to install dthe Qt libraries in my 32bit machine fo rmy app to run? Or can I compile my program so that it runs even when the libraries are not there (I don't want to install the whole Qt there)?

For completeness sake, this is what I get on the 64bit machine:

$ ldd MisterMand 
	linux-vdso.so.1 =>  (0x00007fff41fd4000)
	libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007f3d662f9000)
	libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007f3d65e76000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f3d65c58000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3d65944000)
	libm.so.6 => /lib/libm.so.6 (0x00007f3d656c1000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f3d654a9000)
	libc.so.6 => /lib/libc.so.6 (0x00007f3d65126000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f3d64ef1000)
	libaudio.so.2 => /usr/lib/libaudio.so.2 (0x00007f3d64cd7000)
	libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f3d649f9000)
	libpng12.so.0 => /lib/libpng12.so.0 (0x00007f3d647d2000)
	libz.so.1 => /lib/libz.so.1 (0x00007f3d645ba000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f3d64334000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f3d640ec000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f3d63ee2000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f3d63cc7000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f3d63abd000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f3d638aa000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f3d63574000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f3d63370000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f3d6316a000)
	librt.so.1 => /lib/librt.so.1 (0x00007f3d62f62000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d66fbb000)
	libexpat.so.1 => /lib/libexpat.so.1 (0x00007f3d62d39000)
	libXt.so.6 => /usr/lib/libXt.so.6 (0x00007f3d62ad3000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f3d628cf000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f3d626a1000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x00007f3d6249b000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f3d6227f000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f3d62078000)

$ ldd MisterMand 
	linux-vdso.so.1 =>  (0x00007fff41fd4000)
	libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007f3d662f9000)
	libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007f3d65e76000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f3d65c58000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3d65944000)
	libm.so.6 => /lib/libm.so.6 (0x00007f3d656c1000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f3d654a9000)
	libc.so.6 => /lib/libc.so.6 (0x00007f3d65126000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f3d64ef1000)
	libaudio.so.2 => /usr/lib/libaudio.so.2 (0x00007f3d64cd7000)
	libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f3d649f9000)
	libpng12.so.0 => /lib/libpng12.so.0 (0x00007f3d647d2000)
	libz.so.1 => /lib/libz.so.1 (0x00007f3d645ba000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f3d64334000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f3d640ec000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f3d63ee2000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f3d63cc7000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f3d63abd000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f3d638aa000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f3d63574000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f3d63370000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f3d6316a000)
	librt.so.1 => /lib/librt.so.1 (0x00007f3d62f62000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3d66fbb000)
	libexpat.so.1 => /lib/libexpat.so.1 (0x00007f3d62d39000)
	libXt.so.6 => /usr/lib/libXt.so.6 (0x00007f3d62ad3000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f3d628cf000)
	libpcre.so.3 => /lib/libpcre.so.3 (0x00007f3d626a1000)
	libuuid.so.1 => /lib/libuuid.so.1 (0x00007f3d6249b000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f3d6227f000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f3d62078000)

To copy to clipboard, switch view to plain text mode 

-Manu

[SixDegrees]

Yes, you need all dynamic libraries the executable depends on installed on the machine you're trying to run on. When launched, you will usually see an error message indicating what the problem was; if it involves missing dynamic libraries, the first one missed will be listed in the error message.

[portilhe]

Okay, I realise it was a dumb question... I have to build the application statically. I have to read the documentation here. Thank you all for your replies.

[SixDegrees]

Note that even if you build statically, there is no guarantee that another Linux system will have the same set of system libraries required to run the executable. A number of the libraries in the ldd dump above have nothing to do with Qt, and are not required in a functioning Linux system.

The typical way to distribute executables under Linux is to either package them with something like RPM, which builds dependencies into the package and allows the installer to download those if needed, or to simply tell the user what they are likely to need and let them acquire/install it themselves.

[ChrisW67]

It goes in the other direction. I compiled it on my 64 bit and it's not running on the 32 bit one.

If you compile as a 64-bit application then of course it won't run on a 32-bit operating system: it's like putting diesel into a petrol engine. The same goes with building an x86 executable and expecting to run on an Arm processor even if both are running Linux. (You can build 32-bit applications on a 64-bit platform but this is typically not the default.)

Okay, I realise it was a dumb question... I have to build the application statically.

Assuming your two machines are both x86 architectures then why not try to actually diagnose the problem rather than running off down another path (which is not without its own dramas).

What exactly doesn't work? Does your application fail to launch at all? Launch and do something odd? Report an error message to the console? Share some information and perhaps a solution is minutes away.

[portilhe]

I haven't had the time to look at this since yesterday, but to answer your question quickly, the application does nothing at all. The error message is
"bash: ./MisterMand: no se puede ejecutar el fichero binario" (which is spanish for "cannot execut binary file").
-Manu

[squidge]

You have made sure that the executable bit is set?

[portilhe]

Yes, I did do that (chmod 700 ...)

[schnitzel]

please show the output from the following commands:

file ./MisterMand
uname -a

file ./MisterMand
uname -a

To copy to clipboard, switch view to plain text mode 

btw: you can't run a 64bit executable on a 32bit machine - (unless your pc has certain virtualization capabilities, then you could run the 64bit executable in a 64bit linux guest virtual machine).
You could build a 32bit executable on a 64bit machine by using the -march gcc compile option.

[portilhe]

The code is

$ file ./MisterMand
./MisterMand: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

$ file ./MisterMand
./MisterMand: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

To copy to clipboard, switch view to plain text mode 

$ uname -a
Linux nico-laptop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux

$ uname -a
Linux nico-laptop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux

To copy to clipboard, switch view to plain text mode 

I guess that means I really need to link statically, right?

[wysota]

No, it means you need to build the program for 32 bit architecture. You are currently pouring petrol into a diesel engine and pouring petrol from another gas station will not change a thing. You need a diesel (aka 32bit binary).

[schnitzel]

The code is

$ file ./MisterMand
./MisterMand: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

$ file ./MisterMand
./MisterMand: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

To copy to clipboard, switch view to plain text mode 

$ uname -a
Linux nico-laptop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux

$ uname -a
Linux nico-laptop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:21 UTC 2011 i686 GNU/Linux

To copy to clipboard, switch view to plain text mode 

I guess that means I really need to link statically, right?

not neccesarily - you *can* bundle all libs and executable together into an installer (this is a good read for you: http://doc.qt.nokia.com/4.7/deployment.html)
but... your target architecture needs to be compatible with the produced executable. This doesn't seem to be the case in your example: 32bit target trying to run 64bit executable
This will not work regardless of whether you build the app dynamic or static.

arrgggh [wysota beat me to it]

[portilhe]

Thanks everyone! I shall now embark on a journey to learn how to do that (compile for 32bit on a 64bit machine).
Cheers,
-Manu

[schnitzel]

or (if you have oodles of diskspace and a decent amount of RAM) you could install a 32bit linux guest os in a virtual machine on your 64bit linux host (check out oracle's virtualbox)

[wysota]

Or a chrooted build environment.

Google for "linux compiling for 32 bits on 64 bit machine"