[PATCH][Ffmpeg-devel] Compilation Issue - Policy decision needed!

Michel Bardiaux mbardiaux
Wed Oct 5 10:35:11 CEST 2005

Alexander Strasser wrote:
> Hi,
> Michel Bardiaux wrote:

>>OK, I have 'patched the patch' to remove --enable-runtime-pseudo-reloc 
>>and now I get an error:
>>Info: resolving _ff_log2_tab by linking to __imp__ff_log2_tab (auto-import)
>>Info: resolving _ff_sqrt_tab by linking to __imp__ff_sqrt_tab (auto-import)
>>vp3.o: In function `theora_decode_tables':
>>variable 'ff_log2_tab' can't be auto-imported. Please read the 
>>documentation for ld's --enable-auto-import for details.
>>variable 'ff_log2_tab' can't be auto-imported. Please read the 
>>documentation for ld's --enable-auto-import for details.
>>Creating library file: libavcodec.dll.a
>>make[1]: *** [avcodec.dll] Error 1
>>make[1]: Leaving directory 
>>make: *** [lib] Error 2
>>I'm pretty sure this did not happen when I tried mingw a few weeks ago, 
>>which is why we didnt understand each other. After reading man ld and 
>>googling for --enable-runtime-pseudo-reloc it is now clear that the 
>>latter is intended to fix exactly that king of problem.
>>The question is now rather simple: which minimal version of the mingw 
>>gcc will be mandated for ffmpeg? If we want to support gcc 3.2, then 
>>some changes to the code will be necessary, as described under 
>>--enable-auto-import in man ld.
>   Sorry for my late reply. Anyway good, you understand me
> better now. I didn't mean to be unclear.
>   One of the problems is that there is more than one problem.
> I am pretty busy and I may not get anything done till next week.
>   Additionally I don't have access to development Win32 machine
> atm.

And I cant say I do (have access to one) until the question of the 
minimal version of gcc has been settled.

>   I think there might also be other options to fix this;
> maybe circumventing gnu ld auto-import feature all together.
> But as I said above I could not try out anything for now.

This is a policy decision, for the list 'leaders': do we change code 
(possibly at the expense of performance) just for the sake of the mingw 
port, or do we mandate a minimal version of gcc?

>   Using ms linker to generate import .libs would of
> course still be done.
>   Well, I meant it only for linking ffmpeg program etc.
> The av libs were lately linked in statically even when
> --enable-shared was used. But this doesn't resemble
> what is done in linux/other platforms and was iirc the
> original complaint of the OP. How libs get linked is
> decided by the linker and it chooses normally the
> dynamic version when available. I am not sure how this
> did work out before. Maybe it should be investigated.
>   In my patch i fixed it by letting the gnu linker
> create the import libs as .dll.a which then was used
> when linking e.g. ffmpeg.

I have looked in libavutil and I see way to many files:


The 2 first ones should not be there, I think. But that is not the 
priority now, we'll discuss that later when the reloc issue is solved.

>>>>But it will be
>>>>a bit more involved to implement it properly.
>   Alex (beastd)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles

More information about the ffmpeg-devel mailing list