Thank you for the reply. Indeed, a search on Google has turned up previous reports of this error. This problem being known is more puzzling than enlightening, because obviously if nothing changes you will keep seeing new posts about this every now and then. In http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/079283.html Carl Eugen Hoyos wrote: "I wonder if you should carefully scan configure's output for relevant remarks..." My configure.log says: "libavcodec.so is discouraged over static libavcodec" "using libpostproc.so, but static libpostproc is recommended" "using libswscale.so, but static libswscale is recommended" This is disingenuous. Using weasel words this way in not nice. How about either: A. Making, announcing and documenting a technical decision: Building mplayer against ffmpeg built as a shared library is unsupported for the following valid technical reasons (here I guess): 1. The API and ABI are unstable and the mplayer development team wishes you to use a known good combination. 2. The performance cost of PIC code is too high to be allowed in the recommended configuration. 3. Another valid reason. or B. Patching configure to check whether all required symbols are present in swscale.so, probably depending on which configure options were chosen, and correctly declaring a configuration unbuildable if required symbols for chosen modules are not present. Then the user will not have to waste their time and yours by first waiting for a build to fail and then puzzling over the error and then reporting it. Instead they can go fix their ffmpeg or build against the bundled ffmpeg, without bothering you with bug reports you do not intend to fix. I am willing to work on a patch for option B if there is a chance it will be accepted after proper review. -Zeev
