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?

Reply via email to