[Ffmpeg-devel] [PATCH] Cygwin vhook, always static avformat
Víctor Paesa
wzrlpy
Tue Aug 1 13:01:10 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?
>
> 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
More information about the ffmpeg-devel
mailing list