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

[Alexander Strasser]

Hi,

Michel Bardiaux wrote:
> Michel Bardiaux wrote:
> >Alexander Strasser wrote:
> >>Michel Bardiaux wrote:
> >>>Short version: it all hangs on --enable-runtime-pseudo-reloc. A 
> >>>little google shows it is strongly recommended for all dll builds 
> >>>using mingw, so I suppose we'll want to keep it even if not 
> >>>absolutely necessary. So, what is the minimum version of 
> >>>mingw/gcc/msys I need?
> >>
> >>
> >>
> >>  I don't know when it was exactly introduced, but i guess somewhen
> >>at end of 2002 and beginning of 2003 (not sure tho).
> >>  I am still a little bit confused of the issue as it requires special
> >>options for GNU ld but works (as it seems) flawlessly with m$ linker.
> >>What i have read would rather imply the opposite situation if i
> >>understood correctly.
> >>
> >>  Another question is if we should apply this for now to fix the
> >>situation for people with recent linker versions as the shared build
> >>won't work correctly for the current version anyway?
> >
> >
> >I dont understand at all what you mean. Let me rephrase the questions.
> >
> >(1) What version of gcc do you use?
> >
> >(2) Why did you introduce --enable-runtime-pseudo-reloc? What fails if 
> >that option is not present?
> 
> 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.

  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.

> >>  Maybe the best fix for all is to use the link directly-to-dll
> >>feature you demonstrated in your previous mails.
> >
> >
> >Uh? What do you mean? I dont think VC++ can link to a DLL without a .def 
> >or a .lib.

  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.

> >> But it will be
> >>a bit more involved to implement it properly.

  Alex (beastd)