On Tue, Feb 24, 2009 at 4:45 PM, Stephen Irons <stephen.ir...@tait.co.nz> wrote: > Christopher Sawtell wrote: >> >> On Tuesday 24 February 2009 12:37:45 Stephen Irons wrote: >> > I have installed ffmpeg from the Ubuntu repositories. >> >> >> man gcc >> >> >> pay particular attention to the -L option flag. >> >> >> and then if you are an obedient purist, alter the necessary configuration >> files, generate a new .deb file and install form that. >> >> >> Being an obedient purist is seriously recommended. >> >> >> -- >> With Sincerity, >> Christopher Sawtell > > -L/usr/local/bin as an option to gcc did not change anything. I think that > option only affects static linking -- it tells the linker where to look for > libraries. Or perhaps where to find the stubs necessary to link a library > dynamically. But it did not affect the loading at run-time. > > But I found two solutions: > > 1. ./configure --extra-ldflags=-Wl,-rpath/usr/local/bin stores that path in > the executable to tell the program loader to also search /usr/local/bin for > libraries. > > 2. ./configure --build-suffix=-ZZZ changes the names of the libraries to > lib-avcodec-ZZZ.so.66.whatever. These names are stored in the executable, so > they are found correctly. > > man ld gives the full search order for *linking*: > > * -rpath-link options > * -rpath options > * LD_RUN_PATH environment variable > * On *SunOS*, directories specified using -L -- this is what > Christopher Sawtell suggested, but does not work on Linux > * LD_LIBRARY_PATH > * DT_RUNPATH or DT_RPATH > * default directories /lib and /usr/lib > * directories in /etc/ld.so.conf > > man ld.so gives a different order for *loading*: > > * LD_LIBRARY_PATH > * From the cache file /etc/ld.so.cache, created by ldconfig > * /lib and /usr/lib > > But this does not describe what I actually saw happening, so I prefer the > search order given in man ld. I think that the *linker* was finding the > necessary library stubs in /usr/lib, so it never bothered to look in > /usr/local/lib. > > Anyway, my version of ffmpeg with AMR support is now working...so I can once > again convert videos from my phone to ... whatever ... they are still > rubbish. > > I should probably make a .deb package so that I can install into /usr/bin > and /usr/lib so that other applications get the newer version of ffmpeg and > libav* ... but what will it break? Nothing, provided that the library > authors have got their version numbering correct. > > Stephen Irons
perhaps it would be easier to use the medibuntu repos. My ff,eg from medibuntu boasts: --enable-amr_nb --enable-amr_wb would that do the trick?