On 10/31/2017 11:44 AM, Hendrik Leppkes wrote:
On Tue, Oct 31, 2017 at 6:50 PM, Aaron Levinson
<alevinsn_...@levland.net> wrote:
Signed-off-by: Aaron Levinson <alevinsn_...@levland.net>
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index ea22d692b9..572299c9d3 100755
--- a/configure
+++ b/configure
@@ -3327,7 +3327,7 @@ avformat_deps="avcodec avutil"
avformat_suggest="libm network zlib"
avresample_deps="avutil"
avresample_suggest="libm"
-avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox
corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi videotoolbox
corefoundation corevideo coremedia advapi32"
postproc_deps="avutil gpl"
postproc_suggest="libm"
swresample_deps="avutil"
@@ -5839,7 +5839,7 @@ check_builtin stdatomic_h stdatomic.h "atomic_int foo,
bar = ATOMIC_VAR_INIT(-1)
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 advapi32 "windows.h wincrypt.h" CryptGenRandom -ladvapi32
check_lib psapi "windows.h psapi.h" GetProcessMemoryInfo -lpsapi
enabled appkit && check_apple_framework AppKit
advapi32 contains many more things, while wincrypt refers to the name
of the crypt header specifically, so wincrypt seems a bit more correct
to me.
- Hendrik
I'm aware of this, but it seems to me either we use an approach that has
many different check_lib statements for various API classes, even if the
same library is used for each, or we have a single check_lib statement
that picks a frequently used API from each library. For example, how
did someone arrive at CoTaskMemFree for ole32 when there are plenty of
other APIs implemented in ole32? The same goes for CommandLineToArgvW
in shell32. I could add a general advapi32 check_lib statement in
addition to wincrypt, but the result will be the same--the addition of a
dependency on advapi32. Also, if the argument is, we want to make sure
that we are using a specific version of advapi32 that supports
CryptGenRandom, I could see that applying to a relatively new Win32 API,
but CryptGenRandom has been around since Windows XP, and it is just as
good as most APIs implemented in advapi32 for being the "principal" API
associated with advapi32. Adding a dependency on a component named
"wincrypt", when all we want is access to the Registry APIs, I think is
a bit misleading.
Aaron Levinson
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel