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

[Víctor Paesa]

Hi,

> On Tue, Aug 01, 2006 at 01:01:10PM +0200, V?ctor Paesa wrote:
>> > 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?
>>
>> Mmmh, where is your attached patch?
>> Are you referring to your r5874, r5875 recent changes in common.mak ?
>
> No, I was just suffering from unattached patch disease...

I'm glad you recovered so quickly from your sudden disease :-)

Aaah, your patch is intended for MingW, sorry, I don't use that platform,
your questions should be better answered by MingW people.

Your patch does not alter nor static nor shared libraries compilation
under Cygwin, so it is OK, if wanted me to check that.
And nothing is broken, after applying ffmpeg.cygwin.vhook.6.patch.



Changing topic, I never answered this question:

> >> >>> > --- 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.

Sorry for the later answer, yes, your guess is correct, the reason is that
Cygwin (actually Win32) is not able to link if there are undefined
symbols,
these errors appears if ffmpeg.cygwin.vhook.6.patch is not applied and I
attempt "make vhook":

gcc -fPIC -O3  -g -Wdeclaration-after-statement -Wall -Wno-switch -I..
-I/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg
-I/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavformat
-I/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavcodec
-I/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavutil
-DHAVE_AV_CONFIG_H `freetype-config --cflags`   -c -o null.o null.c
null.c:1: warning: -fPIC ignored for target (all code is position
independent)
gcc -Wl,--warn-common   -Wl,--as-needed
-Wl,-rpath-link,/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavcodec
-Wl,-rpath-link,/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavformat
-Wl,-rpath-link,/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/libavutil -g
-o null.dll -shared -Wl,-soname,null.dll null.o -lImlib2 `freetype-config
--libs`
null.o: In function `Configure':
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:40: undefined
reference to `_av_mallocz'
null.o: In function `Process':
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:56: undefined
reference to `_avpicture_get_size'
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:57: undefined
reference to `_av_malloc'
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:59: undefined
reference to `_avpicture_fill'
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:60: undefined
reference to `_img_convert'
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:71: undefined
reference to `_img_convert'
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:76: undefined
reference to `_av_free'
null.o: In function `Release':
/home/wzrlpy/src/FFMpeg-20060729-5847/ffmpeg/vhook/null.c:33: undefined
reference to `_av_free'
collect2: ld returned 1 exit status
make: *** [null.dll] Error 1
rm null.o

I guess that MingW would benefit of ffmpeg.cygwin.vhook.6.patch too.

Regards,
V?ctor Paesa