Recherche avancée

Sur d’autres sites (6047)

• OpenCV 3.2.0(cmake error in configuration process ) “configure” fails, ffmpeg not downloaded on Windows [duplicate]

  8 février 2017, par O.OZTURK

  This question already has an answer here :

  • OpenCV 3.0.0 “configure” fails, ffmpeg not downloaded
    
    5 answers
    

  I get the following error when trying to configure OpenCV using CMAKE on windows :

  CMake Warning at cmake/OpenCVUtils.cmake:1020 (message) : Download :
  Local copy of opencv_ffmpeg.dll has invalid MD5 hash :
  d41d8cd98f00b204e9800998ecf8427e (expected :
  f081abd9d6ca7e425d340ce586f9c090) Call Stack (most recent call first) :
  3rdparty/ffmpeg/ffmpeg.cmake:10 (ocv_download)
  cmake/OpenCVFindLibsVideo.cmake:219 (include) CMakeLists.txt:557
  (include)

  Downloading opencv_ffmpeg.dll... CMake Error at
  cmake/OpenCVUtils.cmake:1043 (file) : file DOWNLOAD HASH mismatch

  for file: [C:/OpenCV-3.2.0/opencv/sources/3rdparty/ffmpeg/downloads/f081abd9d6ca7e425d340ce586f9c090/opencv_ffmpeg.dll]
  
    expected hash: [f081abd9d6ca7e425d340ce586f9c090]
  
      actual hash: [d41d8cd98f00b204e9800998ecf8427e]
  
           status: [6;"Couldn't resolve host name"]

  Call Stack (most recent call first) : 3rdparty/ffmpeg/ffmpeg.cmake:10
  (ocv_download) cmake/OpenCVFindLibsVideo.cmake:219 (include)
  CMakeLists.txt:557 (include)

  CMake Error at cmake/OpenCVUtils.cmake:1047 (message) : Failed to
  download opencv_ffmpeg.dll. Status=6 ;"Couldn’t resolve host name"
  Call Stack (most recent call first) : 3rdparty/ffmpeg/ffmpeg.cmake:10
  (ocv_download) cmake/OpenCVFindLibsVideo.cmake:219 (include)
  CMakeLists.txt:557 (include)

  Configuring incomplete, errors occurred ! See also
  "C :/OpenCV-3.2.0/opencv_manual/CMakeFiles/CMakeOutput.log". See also
  "C :/OpenCV-3.2.0/opencv_manual/CMakeFiles/CMakeError.log".

• configure : Check for -no_weak_imports in ldflags on macOS

  6 mars 2017, par Luca Barbato

  configure : Check for -no_weak_imports in ldflags on macOS
  Recent versions of macOS provide more POSIX API (in particular,
  
  clock_gettime) than previous versions and recent Apple toolchains
  
  provide all that API, even when targeting older releases without
  
  said API. Disallow linking to functions which might not be available
  
  at runtime.
  To actually have an effect, either add
  
  — extra-cflags="-mmacosx-version-min=10.11" (or any other version
  
  prior to 10.12) or set MACOSX_DEPLOYMENT_TARGET=10.11 when running
  
  configure.
  As a workaround for libav versions without this fix, one can
  
  also add —extra-cflags="-mmacosx-version-min=10.11
  
   Werror=partial-availability" while running configure.
  The -no_weak_imports flag is new in Xcode 8 ; in Xcode 7 it is not
  
  supported. This is not an issue since Xcode 7 only ships with the
  
  10.11 macOS SDK, which lacks clock_gettime.
  Bug-Id : 1033
  CC : libav-stable@libav.org
  
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] configure

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  10 février 2021

  Les grands principes de séparation entre la forme et le contenu, oui ok d’accord.

  Mais t’as bien vu que l’objet de cette proposition, c’est justement d’accepter de faire un compromis pour simplifier la vie de tout le monde : à la fois pour maintenir le truc et à la fois quand on veut les utiliser dans le core et les plugins.
  Le constat de départ je rappelle, c’est qu’actuellement c’est bien des classes sémantiques-tout-ça, mais au prix de circonvolutions hypers lourdes dans le css (t’as jeté un coup d’oeil à boutons.css ?).

  Si on est pas content des quelques icônes qui peuvent se ballader d’office dans certains formulaires ou bouts de squelettes, on règle ça en 1 ligne de CSS hein : .icone-spip { display: none }
  Ou même si on veut les garder et les surcharger : .icone-spip svg { display: none } et voilà.
  Ça me semble pas un très gros prix à payer.