[PATCH][Ffmpeg-devel] Compilation Issue - Policy decision needed!
Alexander Strasser
eclipse7
Wed Oct 5 00:40:00 CEST 2005
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)
More information about the ffmpeg-devel
mailing list