What could possibly be so difficult about porting the Flash Player to Linux?
I’m glad you asked.
The executive summary of what follows would probably be: ensuring that a single plugin binary functions on the widest diversity of Linux/x86 distributions within reason. Read on for the details.
First, we take the existing Flash Player 7 Linux code along with the current revision of the main Player codebase, modify the Linux-specific stuff as needed, and get the plugin to compile in the first place. Then we upgrade the Linux-specific parts to take advantage of all the latest v8 and v9 features. Which APIs to use? That has already been covered in copious detail throughout previous posts.
While we have the plugin limping along on our development machines, there comes a point where we need to hand off builds to our QA team for testing. This is when we notice that the plugin works great on our dev boxes, but hardly or not at all on any other distributions. Generally, the problem is libraries, libraries, libraries. For example, the player dynamically opens libasound.so to dig out the ALSA audio functions. I recently learned that the ‘libasound.so’ symlink is only available on systems with the right devel packages installed. The proper file to open is ‘libasound.so.2’. Hopefully. Repeat for the rest of the dynamic library loads.
Things get more painful when the plugin refuses to load. The first line of debugging is the ‘ldd’ utility to see if the plugin is finding all of the libraries it wants on its new host system. A major problem has been that the plugin wants to find libstdc++.so.6. Certain older Linux systems that we are trying to support only have libstdc++.so.5. This is not something we can plausibly dynamically load at runtime as in the case of libasound.so.2. This is why I wanted to know how to statically link libstdc++.so.6 with the main binary– larger distro range.
Many thanks to participants on the Automake mailing list as well as my contacts at Red Hat, we actually figured out how to do this (it has to do with the way to toolchain is built vs. specific project built options).
Next problem: The plugin does not load on stock Fedora Core 5 or 6 systems. All the libraries are present and resolving this time. So what’s going on? These systems come “hardened” from the start and they don’t like binaries that contain something called text relocations (“textrels”). These textrels are caused by 2 things in this case:
- statically linking libstdc++.so.6
- manual assembly language optimizations
For number 1, we embarked on a new adventure to build a super-special custom toolchain that builds libstdc++.so.6 just right so that it can be static linked with the plugin without those nagging textrels. The ASM optimization bits are giving us some problems but Tinic thinks he has a way to make those functions play ball in order to create a fast binary. So now the plugin works on hardened Linux or SELinux or whatever the right buzzword is; it works with a Linux distro that uses the security feature of randomizing a program’s base address.
I hope I’ve answered your question.