Sometimes, the Flash Player needs to do HTTP stuff. Most of the time, it's enough for the Flash Player to use plugin/browser functions (NPAPI) to achieve this. However, it is occasionally necessary to go above and beyond what NPAPI provides. While the Windows and Mac versions have standard platform APIs to call upon for that little something extra in the HTTP department, the closest thing that Linux has to a standard is the longstanding cURL library.
We started using cURL during the Flash Player 9 development cycle. At the time, we did not assess that cURL was widespread enough to link to it dynamically. So we included it in the binary, as permitted by the cURL license.
During the Flash Player 10 development cycle, we decided to make cURL the end user's responsibility, i.e., dynamically link to cURL, just as we do with a number of other libraries. In doing so, it's one less thing for us to manage internally. Plus, end users can manage cURL-related updates and bug fixes themselves. But wouldn't you know, there are problems with this approach. There are 2 versions of libcurl.so floating about in the wild: libcurl.so.3 (corresponding to cURL < 7.16) and libcurl.so.4 (corresponding to cURL >= 7.16). Most modern distributions come with the latter. But a few stragglers (that we are still committed to support) are still using the former.
A few possible solutions:
- Build and distribute 2 separate binaries, one for libcurl.so.3 and one for libcurl.so.4, thus doubling our own internal testing efforts. Heh, naw, I don't think so.
- Place a hard requirement in the binary to link to libcurl.so.3. Many distros that have libcurl.so.4 have a symlink from libcurl.so.3.
- Place a hard requirement in the binary to link to libcurl.so.4, thereby freezing out any distros that still use libcurl.so.3.
- Manually load the required cURL functions at runtime.
- Sprinkle magic open source pixie dust on the Flash Player (solves all problems, don't ya know). Can you say "nonstarter"?
For the most recent release candidate of Flash Player 10, we opted for choice 2. This seemed to work for most distros except, most notably, Fedora systems which did not feature the symlink from .so.3 -> .so.4. Apparently, there's another reason not to rely on this method, though. The cURL functions are reportedly version-checked so that if the Flash Player links to libcurl.so.3, we are not certain we will actually be getting the most recent code present in libcurl.so.4.
The next thing we are going to try is option 4-- manually load the library, the same as we already do with ALSA and OpenGL. We will use dlopen() and dlsym() to load required functions from libcurl.so.4. If that library is not there, fall back to libcurl.so.3. Look for this behavior in the next release. If that library is not there... why not? Oh, and refuse to load the Flash Player in that circumstance.
I know many users are frustrated that we seem to be spending time on what might be perceived as minor issues when there are certain "bigger picture" items that are a little more visible. Believe me, we share that sentiment. Maybe one day, more of these little items will be standardized so we don't have to use so much developer time making sure 1% of the Flash feature set works correctly on Linux.