A simple question (maybe) can a daemon coded and compiled as 32-bit be run on a 64-bit linux distro? I haven't seen the info anywhere where it can't be.
Yes, you can run 32-bit processes on a 64-bit Linux system. There's nothing special about daemons.
It depends both on architecture support (i.e. executing both 64-bit and 32-bit code) and on specific linux support (providing system calls to both 64-bit and 32-bit code). For amd64 linux, both are true. See, for example:
https://help.ubuntu.com/community/MultiArch
Similarly, ARMv8 supports both 32-bit and 64-bit modes:
https://en.wikipedia.org/wiki/ARMv8#ARMv8_and_64-bit
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
As long as the shared libraries are available in 32-bit, then a 32-bit daemon will run on a 64-bit Linux.
Related
I'm currently working with Sparc V8 architecture Atmel based boards. So, for unit level testing, i'm doing in on my linux machine (Intel x86). Since, x86 is a little endian machine where as Atmel Processor is a big endian processor, all my memory pointers are going for a toss. Will porting a VM with Solaris (Sparc- Big endian OS) and running test help?
Why don't you just install linux on your sparc machine? Linux already has a port for sparc, and it ought to still work on a v8 cpu as the maintainers are pretty careful to keep old stuff working.
You can't run SPARC version of Solaris in Intel VM, it just won't boot.
The only exception is QEMU emulator, but it'll likely be very slow
I'm a long-time user of Cygwin. I'm running Win7/x64, but my Cygwin installation is 32-bit. At the time I installed it, 64-bit version was considered experimental. Now the Cygwin website lists 32-bit and 64-bit versions on their website without any special mentions or recommendations on which one to use.
As a programmer, my experience is: unless specifically designed for capabilities of 64-bit CPUs, very few applications can get any gains by being recompiled for a 64-bit CPU. They might use more memory, though, since each memory pointer now uses 8 bytes rather than 4.
So, my question is: is there any benefit to choose 64-bit Cygwin over 32-bit ones? Should I upgrade my 32-bit installation sooner or later?
Performance/memory benchmark results for common usage patterns (e.g. running common UNIX commands, particular shell scripts etc.) would be very welcome.
If you've upgraded your 32-bit Cygwin to 64-bit, please tell your story - was the upgrade worth it?
EDIT: I've been using 64-bit Cygwin for a while now, and haven't really noticed any differences - good or bad - from the 32-bit version.
After running 32-bit Cygwin at work for a number of years, I recently upgraded to 64-bit. It was quite painless as you can run the two installations side-by-side. For me, there was no noticeable difference in performance though I did not run any benchmarks. The biggest gain for me in upgrading was starting with a new fresh install without any of the cruft that built up over the last few years.
The one disadvantage that I had when running 32-bit Cygwin was that the WoW64 subsystem filesystem redirector silently redirects 32-bit applications. This has the result that running ls /cygdrive/c/Windows/System32/ in 32-bit Cygwin doesn’t actually display the contents of %WINDIR%\System32, but instead %WINDIR%\SysWOW64. Attempts to access files in the %WINDIR%\System32 directory, e.g., ls /cygdrive/c/Windows/System32/nbtstat.exe fail with the error message:
ls: cannot access /cygdrive/c/Windows/System32/nbtstat.exe: No such file or directory
This means that Windows commands installed in %WINDIR%\System32 such as nbtstat and dnscmd aren’t available without modifying the PATH. The work-around for accessing 64-bit Windows files was that the %SystemRoot%\sysnative pseudo-directory had to be used, e.g., to run the nbtstat command, use /cygdrive/c/Windows/Sysnative/nbtstat.
32-bit applications on 64-bit Windows
WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem capable of running 32-bit applications. It is included on all 64-bit versions of Windows and creates a 32-bit environment to run unmodified 32-bit applications on a 64-bit system using DLLs to provide the necessary interfaces.
Windows uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to SystemRoot%\SysWoW64, which contains 32-bit libraries and executables.
32-bit applications are generally not aware that they are running on a 64-bit operating system. 32-bit applications can access %SystemRoot%\System32 through the pseudo directory %SystemRoot%\sysnative.
For 64-bit applications (such as Windows Command Prompt, cmd.exe) there’s no filesystem redirection:
See also: File System Redirection
I ran one I/O heavy benchmark, but even for this the noticeable performance gain is well worth it.
On a cygwin bash shell on Windows 7, I ran a find of many patterns piped to grep and then redirected to a file on the same hard drive in 32 and 64 bit:
32 bit
real 1m58.57s 68% more time
user 0m11.95s 41% more time
sys 0m40.83s 23% more time
64 bit
real 1m10.36s
user 0m8.50s
sys 0m33.05s
I have two Linux C/C++ programs that communicate using shared memory (shm_open, mmap, etc.) with mutex (pthread_mutex_*) and conditional variables (pthread_cond_*) in that shared memory. If both programs are compiled (using gcc) and run in 32-bit Linux (RHEL) machines, they communicate successfully. If, on the other hand, one process is compiled in 64-bit machine, the other is still compiled in 32-bit machine (due to legacy code), and both are run in a 64-bit machine, pthread_cond_wait in the 32-bit process waits forever even after the 64-bit process does pthread_cond_signal. What am I missing here. Or is it impossible to use conditional variables and mutex between a 32-bit and a 64-bit application?
I am using 32 bit openSUSE OS, and I am using a cross compiler to build 64 bit application( it does not support building 32 apps) as our software will be deployed on a machine which is 64 bit OS. As testing on target is not always possible, is there anyway to run this applications on my 32 bit OS.
Use something like QEMU that can emulate a 64-bit processor.
Short answer: No, there is no way.
Longer answer: If you have a 64-bit CPU it may be possible to run a 64-bit virtual machine, even though your host OS is 32-bit. I'm not 100% sure about that, though, you'd have to try it.
Although having a little experience, I am still confused with the question of whether it is necessary to install an application and/or build a C++ program or C++ library under Network File System shared by machines, which have different Linux version (e.g. CentOS release 4.7, Ubuntu 8.10), possibly different bit (e.g. 32-bit, 64-bit) and different versions of compiler (e.g. gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10), gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2.), so that the executable or library files can be used under those different machines? What's the principles here?
For example, on a Network File System, I have an executable built from my C++ program under a machine with CentOS release 4.7, x86_64 ad gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10). I surprisedly find that the executable can be used under another machine with Ubuntu 8.10, x86_64 and gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2. Also all the shared libraries I built on the first machine and used by my program do not complain error when the executable is running on the second machine. I am so worried if the running of the executable built on a different machine will give reliable results?
Another example, I remember a executable built on a 64-bit machine cannot run on a 32-bit machine. But how about the other way around, running on a 64-bit machine an executable built on 32-bit machine? How about C++ library files built and used across different bit machines?
If possible, could you point me to some reference, like some webpage, book,... that are related to my questions?
Thanks and regards!
You really need to test your program on each different configuration to be absolutely sure.
You can usually run 32 bit programs on 64 bit machines so you can probably get away with only a 32 bit version if you want.
You need to be a little careful about which version of gcc was used on each platform. Running a program built with gcc 4 on a machine whose OS and glibc were built with gcc 3 could cause you problems. So make sure that at least the major version numbers match.
Obviously, if you have different machine architectures, Sparc versus AMD64 for instance, you will need different versions. There are even some subtle differences between Intel and AMD so don't get over aggressive with the compiler optimizations and if you program uses SSE instructions (if you don't know what this is then you aren't using it), make sure the SSE set you use is supported by all the machines.
The key issues here are the machine architecture, the availability of the right libraries, and the "ABI" or Application Binary Interface. The ABI specifies how the OS should use machine registers and memory to pass information between different parts of the program, for example, how data is pushed onto the stack to pass arguments to a function. The ABI used by GCC has been known to change from time to time which is why using compatible versions is necessary.
I'm not aware of a book or web page that covers all these things. Start with the documentation for GCC and Binutils. And there is no substitute for good testing.