[Ffmpeg-devel] [PATCH] Cygwin vhook, always static avformat
Tue Aug 1 01:10:21 CEST 2006
On Mon, Jul 31, 2006 at 01:57:27PM +0200, V?ctor Paesa wrote:
> > Diego Biurrun <diego at biurrun.de> writes:
> >> This thread was dormant for a short while, let's revive it..
> >> On Sun, Jul 16, 2006 at 02:00:20PM +0100, M?ns Rullg?rd wrote:
> >>> V?ctor Paesa <wzrlpy at arsystel.com> writes:
> >>> > The next attempt on the vhook, shared lib Cygwin patches, attached.
> >>> >
> >>> > --- ffmpeg-5754-old/configure 2006-07-15 23:00:24.468750000 +0200
> >>> > +++ ffmpeg/configure 2006-07-16 00:09:57.265625000 +0200
> >>> > @@ -587,7 +587,11 @@
> >>> > v4l2="no"
> >>> > audio_oss="yes"
> >>> > dv1394="no"
> >>> > -vhook="no"
> >>> > +VHOOKFLAGS="-shared"
> >>> > +VHOOKLIBS='-Wl,--no-whole-archive \
> >>> > + -L../libavformat -lavformat$(BUILDSUF) \
> >>> > + -L../libavcodec -lavcodec$(BUILDSUF) \
> >>> > + -L../libavutil -lavutil$(BUILDSUF) $(EXTRALIBS)'
> >>> Why is this needed on cygwin but not elsewhere? I guess it has
> >>> something to do with now dynamic symbols are resolved. Wouldn't be
> >>> just as well to always link the vhook libs against lav[cfu]? Doing so
> >>> would allow us to get rid of the -rdynamic stuff which is problematic
> >>> anyway (as in syntax and semantics varying wildly between platforms).
> >> Sounds like a good idea..
> > On second thoughts, this might not be such a good idea after all. If
> > static libs are used, linking them into the vhook modules is not at
> > all good.
> Right, if you configure with "--enable-static --disable-shared" under
> Cygwin (after having applied ffmpeg.cygwin.vhook.6.patch) the vhook modules
> show pretty hefty sizes (even after strip):
> $ ls -lrt *.dll
> -rwxr-xr-x 1 wzrlpy Users 2059264 Jul 31 09:23 drawtext.dll
> -rwxr-xr-x 1 wzrlpy Users 2056192 Jul 31 09:23 fish.dll
> -rwxr-xr-x 1 wzrlpy Users 2055680 Jul 31 09:23 imlib2.dll
> -rwxr-xr-x 1 wzrlpy Users 2052608 Jul 31 09:23 null.dll
> -rwxr-xr-x 1 wzrlpy Users 2056704 Jul 31 09:23 ppm.dll
> -rwxr-xr-x 1 wzrlpy Users 3476992 Jul 31 09:23 watermark.dll
> If you use "--enable-shared --disable-static", the modules are lovely slim:
> $ ls -lrt *.dll
> -rwxr-xr-x 1 wzrlpy Users 10752 Jul 31 09:48 drawtext.dll
> -rwxr-xr-x 1 wzrlpy Users 9216 Jul 31 09:48 fish.dll
> -rwxr-xr-x 1 wzrlpy Users 9216 Jul 31 09:48 imlib2.dll
> -rwxr-xr-x 1 wzrlpy Users 5120 Jul 31 09:48 null.dll
> -rwxr-xr-x 1 wzrlpy Users 7680 Jul 31 09:48 ppm.dll
> -rwxr-xr-x 1 wzrlpy Users 9728 Jul 31 09:48 watermark.dll
> I have read in http://edll.sourceforge.net/ that Gimp authors (and others)
> have found a way to actually trick the linker in creating a DLL plug-in
> which will back link to the main application.
> Hence it is possible to link statically and have small vhooks at the
> same time.
> Being tricky, and related to Win32, the chances of that being accepted in
> FFMpeg are fairly low, so I have not investigated further, specially because
> linking dinamically already fulfills my needs.
> So for me (probably the only vhook user under Cygwin) the fat statically
> compiled Cygwin vhooks are acceptable.
Would the attached patch help you already? It's a small and clean part
of your patch and may shared libs work already. Does it fail with
static libs. Is it worse than what we currently have?
More information about the ffmpeg-devel