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

[Víctor Paesa]

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>


Mmmh, where is your attached patch?
Are you referring to your r5874, r5875 recent changes in common.mak ?

Regards,
V?ctor Paesa