On Sun, Jul 28, 2013 at 11:21:32PM -0300, Fernando de Oliveira wrote: > Sorry, sent to the wrong list. > > $ paco VLC MPlayer FFmpeg Audacity > audacity-2.0.3 ffmpeg-0.8.7 ffmpeg-1.2.1 mplayer-1.1.1 vlc-2.0.7 > > I have three questions. (I'll ignore the mplayer questions, I don't use it). > > Audacity needs ffmpeg version < 0.9, as I learned after trying many > times to build it. > > So, I installed ffmpeg-0.8.7 at /usr/local/ >
I had a similar problem with transcode last year. > ./configure --prefix=/usr/local > > I did install, remove, install, ..., all ffmpegs and at the end the > sequence was: ffmpeg-0.8.7 ffmpeg-1.2.1 > > When trying to see running differences between lua or not lua in VLC, I > discovered it would not play files I normally use to test the build. It > was trying to use /usr/local/lib/libavformat.so.53.5.0 from > ffmpeg-0.8.7, not /usr/lib/libavformat.so.54.63.104 from ffmpeg-1.2.1. Yep. > But just the error console appeared. After, discovered that MPlayer had > no sound output and VLC had also sound problems. > > Only way I found was to move away /usr/local, install VLC an MP, then > move /usr/local back. > > I have tried some *FLAGS, without success. > > Q1: What is, if possible, a more elegant, less dangerous way of doing > such kind of things, directing VLC and MP builds to search the right prefix? > In general. /usr/local is for self-installed system-wide progs and libs, which you want to take precedence over whatever version the distro installed. For us, needing an old version of a specific app, that doesn't match the problem - occasionally it will work (like in my initial tests where I built old ffmpeg in /usr/local after everything else had been installed), but it breaks when something gets updated. What sort-of-worked for me was to build the old version in /opt. I say "sort of" because none of the maintained old versions of ffmpeg functioned correctly fori all the transcode options I tried. (Nowadays I've worked around that by only building tccat, and invoking ffmpeg directly.) Getting that to work at all was messy - I had ffmpeg-0.7.13 in /opt/transcode, added the lib to ld.so.conf, exported the lib/pkgconfig at the front of PKG_CONFIG_PATH, and also exported the lib in LD_LIBRARY_PATH (don't recall why), and put wrapper scripts into /usr/bin for the transcode programs [ export PATH with /opt/transcode/bin at the front, invoke the program in /opt/transcode/bin with any args ]. I suspected that was inadequate because it found the system ffmpeg headers instead of the versions from /opt. Perhaps passing CPPFLAGS or adding "-I/opt/wherever/include" to CFLAGS might let audacity find the right headers. But let's take a look elsewhere : Arch build audacity against ffmpeg-compat - they have many versions of that, but I guess they all work similarly. They specify incdir, libdir, shlibdir in configure. Obviously, they do a DESTDIR install (and drop the programs and everything from /usr/share). I guess that installing into /usr/include/ffmpeg-compat and /usr/lib/ffmpeg-compat must work. If doing a direct install it would overwrite the programs with the old versions. Installing directly into /opt/somewhere keeps the programs, but they will be out of the way for normal use. Either way, it looks as if the old ffmpeg headers will be found from PKG_CONFIG_PATH (that is the only non-standard thing in their audacity PKGBUILD). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
