Trying to run my program in FreeBSD OS, I have the following results:
$ ./myprogram
ELF binary type "0" not known
./myprogram: 1: Syntax error: "&" unexpected (expecting ")")
$ file myprogram
myprogram: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.15,
not stripped
The program is built In GCC on Ubuntu computer. What can I do? Can I build the program for FreeBSD on my Ubuntu computer by changing some build options, or I need to build it in FreeBSD OS? Maybe there is some way to convert executable to format recognized by FreeBSD?
You can run a lot of Linux programs on FreeBSD, see http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html.
If this doesn't work, the easiest solution would be to recompile your program on FreeBSD.
2021-06-21: This answer is outdated. As of 2021, FreeBSD includes Linux® binary compatibility, which will run most Linux binaries, save for those which "overly use i386™ specific calls, as enabling virtual 8086 mode".
A large number of Linux programs can be compiled on BSD systems however they are not the same operating system. Linux and BSD are technically not binary compatible.
These days BSD ships with an ABI (Application Binary Interface) for Linux which will translate Linux sys-calls on the fly (Much how WINE operates). This will allow you to run Linux ELF binaries on BSD systems with a small performance penalty.
That being said, they are not the same operating system and your best bet would be to compile for the target system either by gaining access to it or using a method of cross compiling.
Try branding the executable as a linux executable using brandelf (you still need all the dependent libraries setup though, or try linking it statically
http://www.freebsd.org/cgi/man.cgi?query=brandelf&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html
brandelf -t "Linux" and it should work.
Related
I run my program perfectly on my Raspberry Pi 3 when I run 32bit Raspibian. It is a Linux 5.10.33-v7+ #1 armv7l system. The programs were compiled on this system, in C++. If I copy the executables to another card with that system, it works.
However, these same executables do not run when I use Debian 4.19.181-1 aarch64 Linux 4.19.0.16-arm64 (I copy the compiled file and paste it on the other system ).
When trying to run, it returns:
-bash: ./Myprogram: No such file or directory.
If I try to run with bash Myprogram, it returns:
Myprogram: cannot execute binary file
From what I've researched, this is an incompatible architectural error.
I've already tried changing permissions with chmod.
I think 32bit files should work on a 64bit system.
The "file" command returns:
ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for
GNU/Linux 3.2.0,
BuildID[sha1]=ad484c860b63e0d8735c2b7aa5c69f2e49caaf29, with
debug_info, not stripped
Thank you so much
I understand the problem is the architecture. But why can the same processor (same raspbery) run an armv7l OS and also an arm64 OS? How does compatibility work?
Why does raspberry run both arm64 OS and armv7l OS but not programs?
it's not just a 32 or 64 bit problem .
you are two differents architectures, for your program to work you have no choice, you must recompile it for this architecture.
If you want to make portability you can use systems like "Make".
Basically I'm trying to run eclipse's 64bit linux installer on a 64 bit linux machine, but it's giving me an exec format error. All other solutions I've seen say it's usually an error with it not being the right processor speed.
My question is twofold. 1) What is going on here? 2) How do I properly download and install Eclipse?
I'm running linux through chromebook
Here is the output of a few command line statements
uname#loc:~/Desktop/eclipse-installer$ ./eclipse-inst
-bash: ./eclipse-inst: cannot execute binary file: Exec format error
uname#loc:~/Desktop/eclipse-installer$ file eclipse-inst
eclipse-inst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b621fbc20e80d7ac375ece11a5775fc6686b71c7, with debug_info, not stripped
uname#loc:~/Desktop/eclipse-installer$ uname -m
aarch64
To answer your first question I think this could help:
You are trying to execute a program designed to run on a "x86_64" based processor using a processor designed based on "aarch64" architecture. These are two distinct architectures although they both may be using 64-bits for addressing and so forth, but it's not the matter of the bits. They are two completely different CPU designs.
For your second question I can not help because I don't use Eclipse.
After migrating a Debian 7.6 system from i368 to amd64 I encountered the problem to use some older ELF 32-bit LSB executables. Of course, there is the possibility to setup a secondary 32-bit system (in fact I could use my old one) and to apply chroot(8) or schroot(1). But I do not like the additional admin effort, the performance loss by a wrapper program and a different command sequence.
I am wondering whether there is really no way to run a 32-bit application directly on the x86_64 architecture (as possible, e.g., for HP-UX 11.0)? Both
$ /home/alf/prog32
and
$ /usr/bin/linux32 /home/alf/prog32
just lead to the failure message /home/alf/prog32: file or directory not found. This behavior is observed for all ELF 32-bit LSB executables (Debian i386, downloaded, self-written and compiled C-programs).
I write some programs on linux with C
I want to run these programs on many remote computers, which are installed with fedora or ubuntu
I compiled the program with gcc on local machine, however the excutable file is not workable on remote machines.
for example: I use
gcc -o udp_server udp_server.c
on local machine to get a excutable binary file udp_server and then I copy it to a remote machine and run it there, the error is:
-bash: ./udp_server: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
the local machine: fedora
Fedora release 16 (Verne)
Kernel \r on an \m (\l)
3.6.10-2.fc16.x86_64 GNU/Linux
the remote machine:
Fedora release 12 (Constantine)
Kernel \r on an \m (\l)
2.6.32-36.onelab.x86_64 GNU/Linux
on these remote machines, there are no gcc compiler
so I hope I can make some excutable files so that they can be executed on those remote machines
so what kind of excutable files should I make, and how to make them?
any recommenation tools or procedures?
thanks!
To run a program written in C, you must first compile it to produce an executable file. On Linux, the C compiler is typically the "Gnu C Compiler", or gcc.
If you compile a C program on Linux, it should usually run on any other Linux computer. However, a few conditions must be met for this to work:
A compiled executable is compiled for a specific processor architecture. For example, if you compile for x86-x64, the program will not run on x86 or PowerPC.
If the program uses shared libraries, these must be installed on the target system. The C library, "libc" is installed everywhere, other libraries may not be.
As to how to compile: For a simple program, you can invoke gcc directly. For more complex programs, some build tool is advisable. There are many to choose from; two popular choices are GNU make (the traditional solution), and CMake.
To distribute the program: If it is only a single executable, you can just copy this executable around. If the program consists of multiple files (images, data files, etc.), you should package it as a software package. This allows users to install it using a package manager such as RPM or dpkg. How to do this is explained in various packaging guides for the different Linux distributions.
Finally, a piece of advice: You seem to know very little about software development in general and in C in particular. Consider reading some tutorial on programmin in C - this will answer these (and many other) questions. There are countless books and online tutorials - I can recommend "The C book", by gbdirect.
The issue you see is you are missing a dynamic library on the target machine. To see which libraries you need you need to use "ldd" program. Example (I just execute it against standard program "test" which is in every single linux distribution):
$ ldd /usr/bin/test
linux-vdso.so.1 => (0x00007fff5fdfe000)
libc.so.6 => /lib64/libc.so.6 (0x00000032d0600000)
/lib64/ld-linux-x86-64.so.2 (0x00000032cfe00000)
On Fedora and RHEL you can find which RPM package you want to install using the following command
$ rpm -q --whatprovides /lib64/ld-linux-x86-64.so.2
glibc-2.16-28.fc18.x86_64
And then you need to install it:
$ yum -y install glibc-2.16-28.fc18.x86_64
I dont use Ubuntu / Debian, not sure how to do this. Please note that on 32bit systems libraries for 64bits are not avaiable, but on 64bit systems these libraries have usualla i686 tag and are installable.
Usually, you can execute your program on different machines as long as you keep the architecture. E.g. you cannot execute 64bit program on a 32bit machine, and also vice versa (you can workaround this by installing 32bit libs but thats maybe too difficult).
If you have different distributions, or different versions of same linux distribution, this might be problem - you need to make sure you have all the dependencies in the same major versions.
Or you can link libraries statically which is not usual in the linux world at all, but you can do this. Learn how to use GCC and then you will find out how to do that.
I am using a software for graph mining.
I have got the binary of that software in 2 folders for Linux mode and SunOs mode but don't have the source.
I am able to run the binary in Linux machine.
But when I want to run the binary in a Mac machine I am getting "command not found" for both the Linux and SunOs folders' binaries.
Could someone suggest if it can be able to run this in a MAC machine by any means like using a Linux shell or something
Gaurav
EDIT:I am getting "cannot execute binary" error when I set chmod to "u+x"
You'll need to recompile it for OS X or use a VM.
A command not found just means you're not executing it right, make sure it's chmod u+x and it's either on your PATH, or you specify the path explicitly.
If you use the file command you will see the difference, on the linux executable you'll have something like:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 2.6.15, not stripped
and something like this for OS X executables:
command: Mach-O universal binary with 2 architectures command (for
architecture x86_64): Mach-O 64-bit executable x86_64 command (for
architecture i386): Mach-O executable i386
Operating systems generally don't support executing object code any extra formats... If Mac osx decended from solaris or Linux, then there could be some incentive for legacy support. But just assume everything to be binarily incomparable if it was compiled for a different arch and platform. There are a few places where you inherit backwards compatibility, running 32 but code on 64 bit oses... Or ppc code support on intel macs, but I suspect that both of those, especially the latter were non trivial engineering tasks.
Here are your options...
Get the source and compile on the Mac, if it compiles on Linux and solaris good chance it will compile and run ok on Mac.
Run through an emulator or boot camp