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

[Michel Bardiaux]

Alexander Strasser wrote:
> Hi,
> 
> Michel Bardiaux wrote:
> 
[snip]

>>
>>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':
>>p:/people/michel/internet/ffmpeg-mingw-org/libavcodec/vp3.c:2777: 
>>variable 'ff_log2_tab' can't be auto-imported. Please read the 
>>documentation for ld's --enable-auto-import for details.
>>p:/people/michel/internet/ffmpeg-mingw-org/libavcodec/vp3.c:2791: 
>>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 
>>`/p/people/michel/internet/ffmpeg-mingw-org/libavcodec'
>>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:

libavutil.a
libavutil.dll.a
avutil.lib
avutil.dll
avutil.def
avutil.exp

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
http://www.mediaxim.com/