On Fri, 30 Mar 2018, Diego Biurrun wrote:
On Fri, Mar 30, 2018 at 04:58:29PM +0300, Martin Storsjö wrote:
On Fri, 30 Mar 2018, Diego Biurrun wrote:
> On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lhomme wrote:
> > Le 30/03/2018 à 10:46, Diego Biurrun a écrit :
> > > On Fri, Mar 30, 2018 at 09:36:05AM +0200, Steve Lhomme wrote:
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -4581,6 +4582,7 @@ check_lib ole32 "windows.h"
CoTaskMemFree -lole32
> > > > check_lib shell32 "windows.h shellapi.h" CommandLineToArgvW
-lshell32
> > > > check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom
-ladvapi32
> > > > check_lib psapi "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
> > > > +check_cpp_condition Vista+ windows.h "_WIN32_WINNT >= 0x0600" && check_lib
bcrypt "windows.h bcrypt.h" BCryptGenRandom -lbcrypt
> > > Do you really need to check the Vista condition? What about using bcrypt
> > > unconditionally if available?
> >
> > Yes, you need to use it only on builds that won't run on XP. Otherwise it
> > will fail to load the bcrypt.dll and the whole libavutil DLL (or whatever
> > its form) will fail to load. It would be possible to do it dynamically but
> > IMO it's overkill. It's not really a critical component.
>
> Is bcrypt available on XP? If no then the CPP condition check would seem
> unnecessary. You could just check for bcrypt and bcrypt being available
> would imply Vista. I think I'm missing something.
>
> > But with time if XP support is dropped this check can go and wincrypt
> > dropped entirely.
>
> Is it maybe time to consider dropping XP support?
I wouldn't mind.
Let's go ahead then.
See e.g. 9b121dfc32810250938021952aab4172a988cb56 in ffmpeg; dropping XP
support simplifies the w32pthreads wrapper and allows using better
synchronization primitives, that allow e.g. static initialization of
mutexes.
Do we need to do more changes apart from importing that commit?
Don't think so, except for whatever configure differences there are.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
