Recherche avancée

Sur d’autres sites (11251)

• Build ffmpeg under Cygwin : Invalid relocation. Offset at address doesn't fit into 32 bits

  11 août 2022, par synner

  Trying to build ffmpeg-5.1 under Cygwin, "natively" i.e to be dependant under the cygwin DLL, not necessarily cross-compiling for pure Windows.

  


  I built separately a lot of the dependant libs.
Some of the libs were provided by the cygwin repo naturally.

  


  [ /usr/local/src/ffmpeg-5.1]λ ./configure --disable-shared --enable-static --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" --enable-gpl --enable-nonfree --enable-openssl --enable-gcrypt --enable-libass --enable-libcaca --enable-libcelt --enable-libcdio --enable-libdav1d --enable-libfdk-aac --enable-libfontconfig --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libsoxr --enable-libssh --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libxml2 --enable-libzmq --enable-pic --disable-avdevice

install prefix            /usr/local
source path               .
C compiler                gcc
C library                 newlib
ARCH                      x86 (generic)
big-endian                no
runtime cpu detection     yes
standalone assembly       yes
x86 assembler             nasm
MMX enabled               yes
MMXEXT enabled            yes
3DNow! enabled            yes
3DNow! extended enabled   yes
SSE enabled               yes
SSSE3 enabled             yes
AESNI enabled             yes
AVX enabled               yes
AVX2 enabled              yes
AVX-512 enabled           yes
AVX-512ICL enabled        yes
XOP enabled               yes
FMA3 enabled              yes
FMA4 enabled              yes
i686 features enabled     yes
CMOV is fast              yes
EBX available             yes
EBP available             yes
debug symbols             yes
strip symbols             yes
optimize for size         no
optimizations             yes
static                    yes
shared                    no
postprocessing support    yes
network support           yes
threading support         pthreads
safe bitstream reader     yes
texi2html enabled         no
perl enabled              yes
pod2man enabled           yes
makeinfo enabled          yes
makeinfo supports HTML    yes
xmllint enabled           yes

...


  


  [ /usr/local/src/ffmpeg-5.1]λ ./ffmpeg -version
Cygwin runtime failure: /usr/local/src/ffmpeg-5.1/ffmpeg.exe: Invalid relocation.  Offset 0x7ffd7778b627 at address 0x100a92895 doesn't fit into 32 bits


  


  Suggestions for build options / root cause ?

  


• Revision c3378771b3 : third_party/libwebm : pull from upstream Pulling libwebm from upstream Changes

  2 mai 2014, par Vignesh Venkatasubramanian

  Changed Paths :
   Modify /third_party/libwebm/README.libvpx

  
   Modify /third_party/libwebm/mkvmuxer.cpp

  
   Modify /third_party/libwebm/mkvmuxer.hpp

  
   Modify /third_party/libwebm/mkvmuxertypes.hpp

  
   Modify /third_party/libwebm/mkvmuxerutil.cpp

  
   Modify /third_party/libwebm/mkvmuxerutil.hpp

  
   Modify /third_party/libwebm/mkvparser.cpp

  
   Modify /third_party/libwebm/mkvparser.hpp

  
   Modify /third_party/libwebm/mkvreader.cpp

  
   Modify /third_party/libwebm/mkvreader.hpp

  
   Modify /third_party/libwebm/mkvwriter.cpp

  
   Modify /third_party/libwebm/mkvwriter.hpp

  
   Modify /third_party/libwebm/webmids.hpp

  
  
  third_party/libwebm : pull from upstream

  Pulling libwebm from upstream

  Changes from upstream :
  249629d make Mkv(Reader|Writer)(FILE*) explicit
  7f3cda4 mkvparser : fix a bunch of windows warnings
  5c06178 Merge "clang-format on mkvparser.[ch]pp"
  4df111e clang-format on mkvparser.[ch]pp
  7b24501 clang-format re-run.
  c6767b9 Change AlignTrailingComments to false in .clang-format
  9097a06 Merge "muxer : Reject file if TrackType is never specified"
  eddf974 Merge "clang-format on mkvmuxertypes.hpp and webmids.hpp"
  def325c muxer : Reject file if TrackType is never specified
  41f869c Merge "clang-format on webvttparser.(cc|h)"
  fd0be37 clang-format on webvttparser.(cc|h)
  207d8a1 Merge "clang-format on mkvmuxerutil.[ch]pp"
  02429eb Merge "clang-format on mkvwriter.[ch]pp"
  0cf7b1b Merge "clang-format on mkvreader.[ch]pp"
  2e80fed Merge "clang-format on sample.cpp"
  3402e12 Merge "clang-format on sample_muxer.cpp"
  1a685db Merge "clang-format on sample_muxer_metadata.(cc|h)"
  6634c7f Merge "clang-format on vttreader.cc"
  7566004 Merge "clang-format on vttdemux.cc"
  9915b84 clang-format on mkvreader.[ch]pp
  7437254 clang-format on mkvmuxertypes.hpp and webmids.hpp
  0d5a98c clang-format on sample_muxer.cpp
  e3485c9 clang-format on vttdemux.cc
  46cc823 clang-format on dumpvtt.cc
  5218bd2 clang-format on vttreader.cc
  1a0130d clang-format on sample_muxer_metadata.(cc|h)
  867f189 clang-format on sample.cpp
  4c7bec5 clang-format on mkvwriter.[ch]pp
  9ead078 clang-format on mkvmuxerutil.[ch]pp
  fb6b6e6 clang-format on mkvmuxer.[ch]pp
  ce77592 Update .clang-format to allow short functions in one line
  0a24fe4 Merge "Add support for DateUTC and DefaultDuration in MKV Muxer."
  11d5b66 Merge "Add .clang-format"
  a1a3b14 Add .clang-format
  0fcec38 Add support for DateUTC and DefaultDuration in MKV Muxer.

  Change-Id : Ia0ed161ffc3d63c2eba8ed145707ffe543617976

• New cookie behaviour in browsers may cause regressions

  24 février 2020, par Matomo Core Team — Community, Development

  Last year the Chromium browser team announced they would change their default behaviour for cookies. In particular about a property called samesite. Over the last few months, we have made various changes to our cookie handling to get Matomo ready for this. Depending on your setup and the features you use, some things may not work anymore.

  You can avoid most of the issues by using HTTPS on your Matomo, and ideally also use HTTPS on your website(s).

  If you are not running the latest version of Matomo yet (3.13.3 at the time of writing), then we highly recommend that you upgrade as soon as possible. Previous versions are not compatible with these cookie browser changes.

  Opt out screen

  If you embed the opt out screen on your website running on HTTP, there is a chance the Matomo opt out no longer works. In these cases it may still work over http:

  • when the privacy policy page that embeds the opt out screen (via iframe) also has the Matomo JavaScript tracker embedded,
  • and when both the opt out and the JS tracker point to the same Matomo installation.

  In other cases when HTTP is used, the opt out feature will likely be broken.

  We recommend you test whether the opt out on your site still works by opening your privacy policy page in an incognito browser window. Then test to opt out of tracking, and then reload the page. If the checkbox “You are not opted out. Uncheck this box to opt out.” is still ticked, then your opt out is not working.

  If the opt out is not working anymore, it is most likely due to HTTP being used. In that case you should change the opt out URL to HTTPS. For example change from &lt;iframe src=”<strong>http://</strong>…” to &lt;iframe src=”<strong>https://</strong>...” . If your Matomo doesn’t support HTTPS yet, you will need to contact your webhoster or system administrator to get SSL enabled on your Matomo domain.

  JavaScript tracker

  In most cases, everything related to the JavaScript Tracker will still work as expected.

  But there is an edge case : when you are also reading Matomo’s cookie server side. You may be affected by this edge case issue when :

  • you track part of the user behaviour in the browser (using Matomo JS Tracker),
  • and also track user behavior in your server (for example using one of Matomo SDKs in PHP, Java, Python, C#, etc.).

  In that case, for you to still be able to read the so-called visitorId on your server, we recommend you add this line to your JS tracking code :

  _paq.push([‘setSecureCookie’, location.protocol === 'https:']);

  The cookie can be only retrieved if your website is loaded through HTTPS.

  Should you have any questions, or notice anything isn’t working as expected, please visit our forum.

  Third party cookies

  If you are using third party cookies, using HTTPS on your Matomo is now a requirement to make them work across different domains. Otherwise Chrome and in the near future other browsers would not accept the cookie. If you don’t know if you are using third party cookies or first party cookies, you’re likely using first party cookies and this does not affect you.