[FFmpeg-devel] [PATCH] fix: 'make' with mingw32

Michael Niedermayer michaelni at gmx.at
Tue Aug 12 11:36:01 CEST 2014


On Tue, Aug 12, 2014 at 11:07:11AM +0200, Hendrik Leppkes wrote:
> On Tue, Aug 12, 2014 at 10:42 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Aug 12, 2014 at 10:11:08AM +0200, Hendrik Leppkes wrote:
> >> On Tue, Aug 12, 2014 at 5:48 AM, spanknebel.borken at t-online.de
> >> <spanknebel.borken at t-online.de> wrote:
> >> > From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001
> >> > From: Youka <spanknebel.borken at t-online.de>
> >> > Date: Tue, 12 Aug 2014 04:32:02 +0200
> >> > Subject: [PATCH] fix: 'make' with mingw32
> >> >
> >> > Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) don't auto-include pthread headers, so struct timespec & nanosleep are missing for compilation of libavutil/time.c.
> >> > ---
> >> >  libavutil/time.c | 4 ++++
> >> >  1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/libavutil/time.c b/libavutil/time.c
> >> > index ce4552e..a286fca 100644
> >> > --- a/libavutil/time.c
> >> > +++ b/libavutil/time.c
> >> > @@ -31,6 +31,10 @@
> >> >  #endif
> >> >  #if HAVE_WINDOWS_H
> >> >  #include <windows.h>
> >> > +#if HAVE_NANOSLEEP
> >> > +#include <pthread.h>
> >> > +#include <pthread_time.h>
> >> > +#endif
> >> >  #endif
> >> >
> >> >  #include "time.h"
> >> > --
> >> > 1.8.4.msysgit.0
> >>
> >> Since when is nanosleep a pthread function?
> >>
> >> If its not the usual posix nanosleep, maybe configure should just be
> >> fixed to disable it instead?
> >> I saw a patch on the libav side that did just that, seems like a
> >
> >> better solution to me, since Windows has other sleep functions which
> >> get used instead then.
> >
> > do these other functions provide the same performance on windows ?
> > googling a bit doesnt lead to a conclusive awnser to that but
> > at least one page claimed usleep() to be only millisecond precission
> > and one that its "obsolete"
> > (on windows)
> >
> >
> 
> This specific nanosleep implementation doesn't have any higher
> granularity (I checked its code), it falls back to sleeping by
> milliseconds as well (using Sleep), since Windows just doesn't have
> any higher timer granularity you can use to sleep properly, unless you
> spin.
> 
> Seems to me it makes more sense to just use Sleep directly instead of
> some weird nanosleep hidden in some mingw pthread header.

hmm, ok, applied martins patch in that case, for now

Youka, please tell me in case that doesnt fix your issue or you see
some disadvantage in that solution

Thanks to all

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140812/e70e71ca/attachment.asc>


More information about the ffmpeg-devel mailing list