I had an executable and source code of software made on 64 bit linux want to make that executable run on 32 bit linux. How it can be done in how many ways any easy process
Thankss
The only way I see is to virtualize a 64bits Linux on Virtualbox for example.
But your processor must have a 64bit architecture and support virtualization...
Related
I presently run Linux 2.4.27 (Debian Sarge) on a PowerPC Mac G4 machine. I need to write software for Linux 2.4.18 running on a PowerPC 405 machine, and the binaries I am producing on my Mac G4 running 2.4.27 with both GCC 3.3.5 and GCC 2.95.3 (I have both installed) are having problems; I have built a static version of cURL with both compilers that segfaults when run on this 2.4.18 PowerPC 405 machine. I have noticed that binaries built on a 2.4.18 kernel with a cross compiler work (x86->PPC), however. Unfortunately, the machine that makes those binaries is unavailable to me, and I am really trying to get the Mac to be the "one stop shop" in this development effort (I want to be able to test and run on this machine).
I cannot find a 2.4.18 distribution of Linux for PowerPC anywhere. What can I do to build binaries that will work on a PowerPC 405 machine running Linux 2.4.18 given a PowerPC Mac G4 running a 2.4.27 kernel? Is building GLIBC for 2.2.5 and setting the compilers to use it the answer, or do I have to somehow build a whole kernel of 2.4.18 to support what I am trying to do?
Several weeks later, it appears that the solution suggested by user sessyargc.jp was indeed to use a cross compiler. I am accepting my answer only because I want to close this question out and I can find no way to give sessyargc.jp credit, since he/she only made a comment. Still, thank you sessyargc.jp for pointing the way!
I solved a similar problem in the past, I used the QEMU emulator on my x86 machine.
QEMU emulates the PowerPC-405 CPU too, here is the list of emulated PowerPC CPUs https://github.com/hackndev/qemu/blob/master/target-ppc/STATUS.
QEMU turns your PC in an hypervisor i.e. works like VirtualBox. But QEMU can also emulate CPUs that are different from the host PC one.
You can install and run a PowerPC Linux VM on a standard(cheap) x86 PC and compile your binaries directly in that VM. CPU emulation is a bit slow, but it works.
Regards
I wrote an application in C++ for linux (X11, GLX) and it is working alright on my development computer (32-bit linux on 64-bit capable hardware). However, when I ran it on a 64-bit linux downstairs, I received an error telling me the linker failed to link stdlibc++.so.6, but I thought 32-bit compiled application could run on 64-bit kernels and Oses as well? At least that is the case in Windows... Do I have to separately compile 32 and 64 bit with different libs?
And how do I properly distribute my application? It's a game, and currently you have to run a makefile to let it move its dependencies to the /usr/lib/ directory (a kind of amateur installer). Will this work on all mainstream linux distro's? And are there better, neater ways to release your application?
My .deb package, built on 32-bit Ubuntu and containing executables compiled with gcc, won't install on the 64-bit version of the OS (the error message says 'Wrong architecture i386'). This is confusing to me because I thought that in general 32-bit software worked on 64-bit hardware, but not vice-versa.
Will it be possible for me to produce a .deb file that I can install on a 64-bit OS, using my 32-bit machine? Is it just a matter of using the appropriate compiler flags to produce the executables (and if so what are they), or is the .deb file itself somehow specific to one processor architecture?
The deb installer is probably refusing to install your package because it was (correctly) labeled with a conflicting Architecture: field. i386 code can be executed on an amd64 machine, but it requires that all the appropriate dependencies (32-bit libraries, etc.) be present. It's better to build separate packages for each architecture.
Yes, you can build for 64-bit on your 32-bit machine. It's called cross-compiling, and it requires that you create a build environment for that purpose. To get started, you might want to look up the dpkg-cross and apt-cross tools.
Alternatively, you can just install a virtual machine running a 64-bit OS, and build for your secondary architecture there.
The architecture is just an option in the config file of debian package. By default it uses those from uname. You can override it but there is an easier way.
In general, most 32-bit programs will run fine on 64-bit. However, unless you have a very old PC, it is also very easy to install a mini 64-bit debian in a virtualbox virtual machine. You probably only need base + build essentials + dev libraries. This will not take a lot of diskspace. If you can spare 2G diskspace, just install a desktop debian.
There are more options to do crosscompilation, with various degrees of automation.
I use the virtualbox method regularly. It is easy and fast.
If you run 64-bit linux making a 32-bit environment is as easy as mkdebootstrap + linux32 + chroot.
How is Linux simultaneously 32bit and 64bit? Or is that something handled in glibc?
I run CentOS 5.3 and it is a "64 bit" version; although I build things for 64 bit and 32 bit. From what I think I know, Windows supposedly has a 32bit emulator. Does Linux do the same thing? Is it in userspace or kernel space?
If libc handles it, is it kind of like a emulator that says, I'll link with 32 bit apps, but speak 64 bit to the kernel?
The cpu can execute both 64 and 32bit instructions and the kernel can switch between modes. The only limitation is that you cannot link 32bit programs against 64bit libraries so you must have both 32 and 64bit versions of libc, etc. installed.
Nothing is stopping the cpu from switching from 64bit to 32bit. It just switches.
You can have a 64 bit kernel, and run 32bit apps. You can even have a 32bit kernel and run 64bit apps(Mac os x).
However you need the libaries they use to also be 32bit or or 64bit, which is why you might see files called lib64 or lib32 on linux for the 64bit or 32bit libaries.
Because x86_64 processors are designed over x86 technology, they are still able to support 32-bit programs without any hardware emulation, like what you would need to run x86 programs in a PowerPC or Sparc environment. In Linux, all you need to do is install the necessary software libraries to run the 32-bit software.
Hi I am using Fedora 10 linux with 64bit architecture. I have created 64bit rpm file for my application. It works fine all fedora 10 linux which have 64 bit. But my application doesnot work well for 32 bit linux. So how to convert 64bit rpm file into 32 bit rpm file. Or how to recreate 32 bit rpm file.
Thanks
Sunil Kumar Sahoo
You will need to have 32bit libraries installed on your machine and while package is being build/compile, compiler will need to get -m32 option. I came across this solution:
CC='gcc -m32' CXX='g++ -m32' linux32 rpmbuild --rebuild --target=i586 package.src.rpm
But I didn't try it myself.
Hops it will help you somehow.
BR,
Dawid.
You can use the way Czlowiekwidmo has mentioned or if you have a machine with 32 bit architecture you can set up the same environment as you have setup for 64 bit. follow the same process for rpm creation as you have done for 64 bit then you will get rpm for 32 bit.
Maybe a bit more than you ask for but have you ever looked at http://build.opensuse.org/ ? It's a fantastic build service that allows to build packages for a vast number of Linux distributions (including Fedora 10 - however marked as DISCONTINUED).
Apart from using the superb web-interface, you can also build locally (just in case, your package is closed-source?).
And yes, building both 64 bit and 32 bit packages is supported, along with building 32 bit support libraries for 64 bit platforms.
You can also use "mock" command. "yum install mock", then "man mock", you will find how to use it.
The similar question was answered here:
https://serverfault.com/questions/200712/how-to-create-rpm-for-32-bit-arch-from-a-64-bit-arch-server
One example for mock:
mock -r fedora-10-i386 --rebuild foo.srpm