[Ffmpeg-devel] [PATCH] Cygwin vhook, always static avformat

[Diego Biurrun]

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?

Diego