After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774106 - gst-libav fails to build on windows 7 x-64
gst-libav fails to build on windows 7 x-64
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: cerbero
1.10.0
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-08 15:08 UTC by Keith Thornton
Modified: 2018-04-18 11:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
compiler output (9.34 KB, text/plain)
2016-11-08 15:08 UTC, Keith Thornton
Details

Description Keith Thornton 2016-11-08 15:08:33 UTC
Created attachment 339323 [details]
compiler output

the compile step returns errors when building libav on windows 7 x64 Service pack 1 (VMWare virtual machine).
The errors may be due to wrong setting of WIN_VER or similar. see attached libav-error.txt
Comment 1 Sebastian Dröge (slomo) 2016-11-09 07:21:16 UTC
Can you get ffmpeg and try to build it independently of gst-libav in the cerbero shell? It seems like some detection of features in the configure script there is broken.

Also note that no matter what Windows version you build on, we use the same headers and toolchain. I was building the binaries on Windows 10 FWIW.


Most likely this is a bug somewhere in ffmpeg's conditional use of that API and handling the Windows version defines. Relevant part of the code is in compat/w32pthreads.h:

> #if _WIN32_WINNT >= 0x0600
> #define InitializeCriticalSection(x) InitializeCriticalSectionEx(x, 0, 0)                         
> #define WaitForSingleObject(a, b) WaitForSingleObjectEx(a, b, FALSE)
> #endif

Note that we define -D_WIN32_WINNT=0x0501 for our builds in cerbero.
Comment 2 Keith Thornton 2016-11-09 07:34:15 UTC
I believe InitislizeCriticalSectionEx was introduced in Vista because InitializeCriticalSection leaked memory. ffmpeg have probably updated to use InitializeCriticalSectionEx but this is only compilable if -DWIN32_WINNT= 0x600 or higher
Comment 3 Sebastian Dröge (slomo) 2016-11-09 07:36:24 UTC
Yes but we set it to 0x0501 :) So something is weird here.
Comment 4 Keith Thornton 2016-11-09 08:08:42 UTC
where is -DWIN32_WINNT set, I would like to try it out with 0x600.
Comment 5 Sebastian Dröge (slomo) 2016-11-09 08:12:25 UTC
cerbero/config/windows.config
Comment 6 Keith Thornton 2016-11-09 08:38:36 UTC
ffmpeg compiled
Comment 7 Sebastian Dröge (slomo) 2016-11-09 08:44:47 UTC
So the question now is what the difference between the two builds is, where the overriding #define for _WIN32_WINNT (note the underscore in the beginning) is happening. And why it doesn't happen for me on an even newer Windows.
Comment 8 Keith Thornton 2016-11-10 09:53:58 UTC
I un defined and redifined -DWIN32_WINNT=0x0600 in compat/w32pthreads.h and it compiled.
Comment 9 Sebastian Dröge (slomo) 2016-11-10 10:00:42 UTC
But we don't want _WIN32_WINNT=0x0600 (yet), see bug #756866

Why does it fail if you don't do that? :)
Comment 10 Keith Thornton 2016-11-10 10:06:21 UTC
If it is left as 0x0501 it tels me that InitializeCriticalSectionEx is implicitly defined. The compiler settings convert warnings to errors (see original attachment)
Comment 11 Sebastian Dröge (slomo) 2016-11-10 10:46:20 UTC
But #if _WIN32_WINNT < 0x0600, then it will never ever be used anywhere in ffmpeg according to compat/w32pthreads.h. Only #if _WIN32_WINNT >= 0x0600, then it will be used wherever the non-Ex versions are used.

You say it fails for you #if _WIN32_WINNT < 0x0600 because code uses that function (as in your log). But I don't see how.


So something seems very broken here. Or what am I missing?
Comment 12 Keith Thornton 2016-11-10 10:52:31 UTC
I'm afraid I don't know. I now have a complete 1.10. I suggest we leave the bug sleeping or close it and wait till somebody else has the same problem.
Comment 13 Sebastian Dröge (slomo) 2016-11-10 11:24:19 UTC
You mean you can't reproduce it anymore?
Comment 14 Sebastian Dröge (slomo) 2018-04-18 11:28:52 UTC
Thanks for taking the time to report this.
However, you are using a version that is too old and not supported anymore by GNOME developers. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes by GNOME developers for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.

Please feel free to reopen this bug report if the problem still occurs with a recent version of GNOME, or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.