Hugo Doria schrieb:
With --disable-fribidi (instead of --enable-fribidi) it's building fine, right?
This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi.
No, it is not. This is mplayer's brain-dead, stupid and completely unlogical buildsystem. This is how the logic works in autotools: ./configure Feature foo is enabled if all necessary libraries are detected and disabled otherwise. ./configure --enable-foo Feature foo is always enabled, if some libraries are missing, configure bails out with an error. ./configure --disable-foo No tests are run for the feature foo, it is always disabled. Now, the mplayer configure applies a different, badly documented and brain-dead logic to the --enable-foo case: ./configure --enable-foo Feature foo is always enabled and all tests for necessary libraries are skipped. Furthermore, no -L, -l and -I flags are added to gcc that would be necessary to compile feature foo. It is expected that the user adds those flags to the Makefile himself (but it is completely undocumented WHERE they should be added). This means that if --enable-foo requires any additional compiler flags, using it essentially breaks the whole build process. Some people on the mplayer team seem to think this is a good idea, but it is actually counter-intuitive and unhelpful for distribution packages. If you want to actually --enable-fribidi, you can do so by NOT adding any configure flag. If you are not building in a clean chroot, then you have to add --disable-foo flags for all features you want to disable. And there is no way to make sure a feature was actually enabled, unless you carefully check the full output of configure.