It seems ffmpeg requires that you have X installed, even though ffmpeg itself ought to be buildable without X. Rather stupidly, the ffmpeg code for ffplay.c says: #if defined(__linux__) #define HAVE_X11 #endif Reproducible: Always Steps to Reproduce: 1. emerge ffmpeg on a system with no X 2. er... 3. that's it Actual Results: gcc -Wl,--warn-common -rdynamic -g -o ffplay_g ffplay.o cmdutils.o -L./libavformat -lavformat -L./ libavcodec -lavcodec -lm -lz -ldl -logg -lvorbis -lvorbisenc -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthreadffplay.o(.text+0x68c): In function `main':/var/tmp/portage/ffmpeg-0.4.7/work/ffmpeg -0.4.7/ffplay.c:1692: undefined reference to `XOpenDisplay'ffplay.o(.text+0x6be):/var/tmp/portage/ ffmpeg-0.4.7/work/ffmpeg-0.4.7/ffplay.c:1696: undefined reference to `XCloseDisplay'collect2: ld returned 1 exit statusmake: *** [ffplay_g] Error 1!!! ERROR: media-video/ffmpeg-0.4.7 failed.!!! Function src_compile, Line 54, Exitcode 2!!! make failed. Expected Results: I'd suggest a patch to fix the braindeadedness in ffplay.c. Failing that, the ebuild should include the dependency on X. Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.5-gentoo-r1) =============================================================== == System uname: 2.6.5-gentoo-r1 i686 VIA Nehemiah Gentoo Base System version 1.4.10 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=i686 -O3 -pipe -fomit-frame-pointer -march=i686 -msse -mfpmath=sse" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config / usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=i686 -O3 -pipe -fomit-frame-pointer -march=i686 -msse -mfpmath=sse" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox userpriv" GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://ds.thn.htu.se/linux/gentoo http:// ftp.snt.utwente.nl/pub/os/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="acpi alsa apm avi berkdb cdr crypt curl encode gdbm gif gpm gtk2 imlib jpeg kde libg++ libwww mad mikmod mpeg ncurses offensive oggvorbis perl png python quicktime readline samba slang spell sse ssl svga tcpd usb x86 zlib"
I just discovered it's fixed in media-video/ffmpeg-0.4.8.20040322 So maybe the right thing is to hurry up and get that out of ~x86 :-)
Could backport the fix, although for the moment I could see just adding virtual/x11 to the deps to cover the bases :) Thoughts/preferences?
Its my opinion that you should never make a librarypackage depend on X or gtk just because a demonstrationsoftware that is a part of the package want it. Better to fix the breakage.
Err... look at the code. Granted the actual usage of x functions is minimal (pretty much pulling width/height for usage w/ fullscreen)- anyone familiar w/ sdl who could recommend an equivalent function would be appreciated to chime in now. What would be nice is detection of sdl emerged w/ X enabled (in which case the code *would* be of use)- since we can't detect that currently, unsetting HAVE_X11 is a simple enough fix. Meanwhile, like I said, anyone know of an equivalent set of libsdl functions?
Brian: any news on this ?
This is fixed in the latest ffmpeg.
