Language Selection

English French German Italian Portuguese Spanish

Binary Portability in Linux

Filed under
Linux

An interesting topic for a change: is Linux binary portable? That is, can we take a binary file and be sure it’ll run in any other Linux system? What happens if we broaden that to any POSIX system, will it blend? Eh, I mean, will it run?

Doing some research on the subject I wrote down a list of the thought process which led my to an (inconclusive) answer:

1. First we should define what a binary is for us: When we talk about a binary we are usually thinking about a compiled binary file, not an interpreted script file like Ruby or Python. Those are for people who like things to actually work, so let’s focus on a compiled executable file, like a C/C++ application.

2. Defining compiled file: What could it be other than a sequence of bytes the microprocessor can understand? Yes, that’s right, it’s sort of interpreted code, only there’s electronics behind, not more code. This brings us to the first interesting conclusion: the executable must be (leaving emulators aside) compatible with the architecture you’re on. Running Sparc? Well then, the binary better be compiled for Sparc because otherwise to the uP will not make any sense.

rest here




More in Tux Machines

Android Leftovers

Leftovers: OSS

Ubuntu 16.04 Review: What’s New for Desktop Users

Ubuntu is a tricky distribution. As much as I love it on my home server, my desktop is a different ballgame. In my experience, releases between LTS versions have many new technologies that may or may not survive in the next LTS. There were many technologies or features that Canonical thought were ambitious -- HUD, experimenting with menus, online dash search, Ubuntu Software Center, etc. -- but they were abandoned. So, if I were to use Ubuntu on my desktop, I would still choose LTS. Read more

Workflow and efficiency geek talks Drush and Drupal

I started using Drupal because I needed an open source content management system (CMS) to use in several community projects. One of the projects I was involved with was just getting started and had narrowed its CMS selection down to either Drupal or Joomla. At the time I was using a different framework, but I had considered Drupal in the past and knew that I liked it a lot better than Joomla. I convinced them to go with the new Drupal 6 release and converted all of my other projects for consistency. I started working with Drush because I wanted a unified mechanism to work with local and remote sites. My first major contribution to Drush was site aliases and sql-sync in Drush 3. Read more