cURL Tradeoffs

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). 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:

  1. 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.
  2. 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.
  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.
  4. Manually load the required cURL functions at runtime.
  5. 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.

31 Responses to cURL Tradeoffs

  1. Sat_ says:

    Keep up the great work.I’ve dropped the 64 bit version of kubuntu for a 32 bit slackware and I’m not looking back. so there’s no more need for a 64 bit version if you ask me :รพ

  2. Just link to the latest libcurl and let the user update their systems themselves. Trying to please everyone is the shortest path to failure. [ I described in the post, we have additional constraints and commitments. -Mike M. ]

  3. Vasilis Vasaitis says:

    Another problem that some of us have with linking libcurl dynamically is actually the whole 64-bit thing: I have a 64-bit system and I run flashplayer through nspluginwrapper, and I discovered that I couldn’t run the latest beta simply because libcurl wasn’t included in the 32-bit compatibility libraries (Debian here). This can actually be a big showstopper to us, so if you guys persist on the dynamic linking I hope the 64-bit distros catch up pretty soon.

  4. Matt says:

    I noticed that with the previous 10rc that 64bit users are required to install a large number of dependencies to attain 32bit libcurl support.So it seems (to me a 64bit lay-person) that opting for this new libcurl approach has come at a considerable cost to your existing users who use 64bit platforms.Given this, what are Adobe’s reasoning for this new method with regard to 64bit Linux users. Or is it simply that because 64bit Linux is not an officially supported platform that 64bit will not feature in current rc design decisions?

  5. Michael says:

    Looks good. I hope your final build runs great. Proprietary software in an FOSS world is one of the hardest things to accomplish, and you have turned Flash from a deprecated POS (Flash 7) into an almost perfect, flexible package. Don’t forget that.

  6. Steven says:

    Another option is to have a small curl abstraction library in flash. Detect at runtime whether curl 3 or curl 4 is present, then your abstraction library can dlopen the correct one and the rest of flash doesn’t care.Or better, you can do like nvidia does with its kernel modules; provide unlinked object files to distributions and put the onus of linking the plugin on the distribution.Or, even better, give us the source! Then all these ABI compatibility problems go away ๐Ÿ™‚ [ IOW, extend libflashsupport to cover libcurl. That seemed like severe overkill. -Mike M. ]

  7. The missing 64 bits version is becoming a larger problem with all the dynamic dependences required by FP10rc.Thanks for making mention of the 64bits version though ๐Ÿ˜‰

  8. dreams says:

    Despite the constant crashes I experience with both Flash 9 and Flash 10rc, I’m delighted Adobe continues to support Flash on Linux, thank you for your continued efforts, we do appreciate it very much. Now, if only I could win the lottery and donate a large sum to Linux Flash development.

  9. oyvind says:

    Heh, I can certainly understand the situation. Linux has some way to to go wrt. standard APIs (or versions of the APIs/libs) above the common low-level C stuff. But is it really that much work to just include curl statically linked, like before ? Compared to dyn-linking, fallbacks, dlopen-magic, breakage and that sort of stuff .. :)Anyway, keep up the good work, I’m actually pretty happy with FP 10RC, this looks good.

  10. Peter says:

    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.

    I’m sorry to inform you that this is sheer idiocy. It’s incompetent thinking like this that is the reason why so much software distributed as binary only sucks so much in system integration.Why? There is a reason why .so.3 and .so.4 versions have different sonames. To paraphrase you, can you say “binary compatibility”? Loading symbols from one of two different binary incompatible libraries and treating them the same after that will break at runtime, in awful ways (mysterious crashes are the most popular).Consequently, you’re wrong about .so.3 being a symlink to .so.4. on some systems, it’s a different version. If what you think is done worked, there would be no need to bump soname’s version on libcurl in the first place!And of course, none of these “solutions” of yours will work next time libcurl gets an ABI-incompatible update. Unlike shipping as sources (yeah, I know you hate the idea, but the fact is that it actuall does solve exactly this problem) or bundling libcurl in the plugin. Bundling is one thing you got right, so it’s beyond me why you want to break it now…Another option for you is to do what VMware (you know, the competent binary-only distributor) does: ship all shared libs dependencies with the app and prefer to use system-wide installed ones, falling back to your copy if they’re missing.Sorry for the rant, but it pisses me off that Adobe is so cheap they can’t hire somebody who actually gets development for Linux ๐Ÿ™

  11. Tom Callaway says:

    For what it is worth, in point 2, “many distros” is not correct. The only distros I can find which do this are Debian (and Ubuntu, which lifted it wholesale from Debian).

  12. just another debian user says:

    On behalf of the open source community, please accept my apology for making life utterly miserable for ISVs to try and distribute software.What’s worse is that the more ISVs try to integrate with existing libraries (eg cURL), the more miserable the situation becomes.mea culpa

  13. Martin Povolny says:

    dlopen is a pretty standard way to do such things.I use the same technique on Windows to load the right process-management API on different versions of windows.Don’t uderstand your cries about ‘standards’.I would say that if you don’t like the job, find a different one.

  14. belegdol says:

    The symling from so.3 to so.4 has been added to Fedora libcurl package, but I’m not sure if it’s pushed already. AFAIK the soname bump was a mistake since the ABI is the same.

  15. Kevin N says:

    I wonder why you claim “Sprinkle magic open source pixie dust on the Flash Player” is a “nonstarter”. Do you or Adobe have a position or opinion on the cost benefit of an open source vs. proprietary Flash Player?Obviously folks at Adobe have decided to keep the player proprietary for now, but I’d love to see a public discussion on both technical and business rationale for that decision. I’m not an OSS partisan, I do see the benefits of proprietary software (Photoshop, and the rest of CS for example). In this specific case (a freely distributed platform runtime), I don’t see the value of keeping Flash Player proprietary. I (and others I’m sure) would really like to know what the concerns are. ๐Ÿ™‚

  16. default says:

    @PetercURL kept API compatibility but still changed the library version number for unknown reasons. If they made changes that break compatibility now, they’d have to bump the version number again. I don’t see what’s wrong with the new approach used by Flash in the current situation.

  17. Dave Taylor says:

    Option 3 for me and for any future similar problems follow the LSB. It’s got traction in all the major distributions and this is exactly why it exists so use it. It’s this kind of thing that keeps people writing for OSS instead of ALSA when nobody uses it apart from a few propriety software writers.

  18. Gravis says:

    statically linking the libs would resolve the libcurl issue. perhaps when a proper file name is settled upon, you can return to dynamically linking.

  19. Robert says:

    From daniel.haxx.se: “The ABI for libcurl did change between soname 3 and 4, but the change was in a rather subtle area (FTP third party transfers, sometimes known as FXP) which is rarely used. It certainly will not hurt the Adobe Flash system.”

  20. Zbigniew L. says:

    Link flash 10 to /usr/lib/libcurl.soThis solves everything.Distro developers will have less work by not creating link to fake old curl. Now we are forced by Adobe to create such ugly hack.

  21. SvdB says:

    Another approach:For each version of libcurl, create a shared library libcurlwrap.so which has no objects of its own, but which is linked against that specific version of libcurl. Then link the flashplayer against libcurlwrap.so instead of against a specific libcurl.During installation, check which version of libcurl is available, and install the appropriate libcurlwrap.so.Building the libraries would be as simple as doing:$ ld -s -shared -o libcurl4/libcurlwrap.so /…/libcurl.so.4Checking if you can use version 4 of the libcurl library:$ ldd libcurl4/libcurlwrap.so | grep –silent “not found”

  22. webjdm says:

    I think you must build flash 10 with libcurl.so.4

  23. Abaddon says:

    Does this version depend on xul-runner or firefox?! [ No. -Mike M. ]

  24. Brenda W. says:

    Would asking for a 64bit version a waste of time? x.x

  25. steveL says:

    > Link flash 10 to /usr/lib/libcurl.so> This solves everything.Is this true?(Seems reasonable to me, and multilib distros can patch or build with another libdir.)

  26. R2D2 says:

    What so bad about the current solution?If you’re about to introduce new dependencies please ensure you don’t break stable systems like Firefox 3 did:http://blog.angulosolido.pt/2008/08/firefox-3-gtk-210-horror-show-open.htmlhttp://blog.angulosolido.pt/2008/08/firefox-3-gtk-210-horror-show-community.htmlEither keep static linking or make sure you test on old systems as well as new ones.Please think twice before making flash upgrades too messy.

  27. Luke says:

    libcurl.so.3 is installed on many Fedora systems in other locations, e.g.:/opt/Adobe/Reader8/Reader/intellinux/lib/libcurl.so.3/opt/openoffice.org2.2/program/libcurl.so.3(there’s even /usr/libexec/autopackage/libcurl.so.2/, what a mess…)

  28. Luke says:

    One other whacky solution: hold off on statically linking until the RPM is installed ๐Ÿ™‚

  29. Steve says:

    Ah perfect. Now I get to install a bunch more 32-bit libraries so that I can run Flash on my 64-bit system but will never be used by anything else!

  30. Vadim P. says:

    Seems to me like Linux is failing hard again on standadization. Unfortunately.

  31. WTF says:

    Damn,burn all the 64 bit users.