Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
So I have elf executable file from a montavista linux ARM device and I wanna know if I can run this application on another ARM device, different linux distro, and/or a desktop machine using some sort of "emulator" or tool kit.
The file command says the file is:
ELF 32-bit LSB executable, ARM, version1, dynamically linked (uses shared libs), for GNU/Linux 2.4.17, not stripped
Something else I'm curious about is the file format itself. I'm trying to use a device that will be able to communicate with data from this executable so I loaded the file into IDA decompiler and noticed there's a ton of entries for files that aren't on the operating system. Does this file format store "files" inside it that are accessed through commands? Can I extract these files?
Sounds more like the usual runtime problem. Your system doesn't have the runtime libraries the application needs.
SOME applications outright will not run - these are the ones that look at kernel internal structures for information. They depend on the specific kernel they were built for, or the specific kernel major version (there has been a LOT of changes between 2.4 and 6.x).
The applications that will run do not depend on the kernel - they use the standard application interfaces. These applications may not run because the depend on libraries that DO depend on kernel interfaces. Most likely, the C runtime (which HAS been updated) might not be compatible - some things do change even in user space (libc specifically). If the application doesn't use those it SHOULD run. Other libraries such as libpthread changed a LOT, so multi-threaded applications might not run.
BTW, the specific answer to your question is No. The ELF format does not contain files. It is a description of how to combine the contents of the file with other files (shared libraries) to create a complete execution environment for the application.
Sorry it took a while to respond but would you be able to expand on your comment regarding kernel specific applications? Is there a way to determine if the application I have requires kernel specific binaries to run? Or would the only way to test that be putting the application on another arm device and seeing if it runs?
It almost depends on the hardware platform and where the dependency lies.
In some applications the kernel doesn't really get involved - these can go directly to the device registers (after having the kernel map them to the application) and then do things - direct platform dependency.
Kernel dependency is caused by using kernel data structures for access to data - these are tied to the specific kernel as a new version may change the data structures, or change where/how they are accessed. Many of these have been added to the sysfs filesystem so that when the kernel changes, the access (via sysfs) doesn't change. But when the data structure itself changes, sometimes the sysfs access must also change, and again cause application problems.
I would expect the application documentation to cover both of these possibilities. I think the second shows up by having the process open /dev/mem or /dev/kmem (and /boot/System.map file) to gain access to the data.
The "ldd" command will list the libraries an application needs, and, if they are available, will show them as being mapped.
SOMETIMES, creating a symbolic link of the old name pointing to the current library will work. For such an old one though, this would be unreliable (specifically changes to libc have been rather large - but still, might work).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.