Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th September 2021, 21:15   #41  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 680
I wanted to release new FFmpeg binaries, but I'm having difficulty creating error-free binaries. I need some more time, if I can fix it at all. "When it's done", I guess.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 6th September 2021, 00:22   #42  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 1,665
No worries, there's no rush.
FranceBB is offline   Reply With Quote
Old 11th September 2021, 23:30   #43  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 680
A couple of headaches later...
Earlier this evening I've uploaded new binaries. Changelog in post #1 as usual. And my Github repo is already up-to-date as well.

At first libass its DirectWrite implementation caused a compilation-error.
Next a successfully compiled FFmpeg binary crashed immediately with the Windows error-message "The procedure entry point InitializeConditionVariable could not be located in the dynamic link library KERNEL32.dll".
Doing a search for "InitializeConditionVariable" among the compiled and installed libraries returned:
Code:
[...]/i686-w64-mingw32/lib/libwebp.a
[...]/i686-w64-mingw32/lib/libx265.a
For further testing I've compiled FFmpeg without --enable-libwebp and --enable-libx265, but it now crashed with the Windows error-message "The procedure entry point K32GetProcessMemoryInfo could not be located in the dynamic link library KERNEL32.dll".
Lots of searching and reading and through https://www.mingw-w64.org/changelog I landed at...

https://sourceforge.net/p/mingw-w64/mailman/message/37287751:
Quote:
_WIN32_WINNT is now set to Windows 10 as default.
I had updated Zeranoe's "MingGW-w64 Build Script" to r32, which uses MingGW-w64 9.0.0. Reverting MingGW-w64 to 8.0.2 resolved all errors.

The strange thing is that, unlike 'libwebp.a', 'libx265.a' still contains "InitializeConditionVariable" (a function not available on WinXP), but using -c:v libx265 seems to work just fine (so far).

I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?
__________________
My hobby website
Reino is offline   Reply With Quote
Old 11th September 2021, 23:59   #44  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,225
Quote:
Originally Posted by Reino View Post
I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?
You #define _WIN32_WINNT (or set it via -D_WIN32_WINNT command-line option) to specify the version of Windows NT that you are targeting.

And you have to do this before #include'ing the <Windows.h> header file, or before #include'ing anything that implicitly #include's the <Windows.h> header file – otherwise it will have no effect at all!

Anyways, all that _WIN32_WINNT really does is to enable/disable the declaration of certain Win32 API functions (in the header file, and only there), depending on whether they were available in the target Windows version.

It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail


Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!

If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.

For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.


Last but not least, latest MinGW-w64 still can produce binaries that run on Windows XP, i.e. MinGW-w64's own runtime apparently doesn't use any Win32 API functions that weren't available in Windows XP.

But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64. Obviously, libwinpthread uses Win32 API functions only available on Vista and higher – and there's not much you can do about that. Consequently, as soon as the application code (or any of the dependencies that you are linking in) uses multi-threading via the pthread-API, then the resulting binary won't run on Windows XP. At least when using libwinpthread.


As an aside: Dependency Walker (or, on modern Windows versions: Dependencies by lucasg) is your friend!
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 12th September 2021 at 01:49.
LoRd_MuldeR is offline   Reply With Quote
Old 13th September 2021, 00:08   #45  |  Link
Reino
Registered User
 
Reino's Avatar
 
Join Date: Nov 2005
Posts: 680
Quote:
Originally Posted by LoRd_MuldeR View Post
(or set it via -D_WIN32_WINNT command-line option)
Which I assume is a cmake option?

Quote:
Originally Posted by LoRd_MuldeR View Post
It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail
Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.

Quote:
Originally Posted by LoRd_MuldeR View Post
Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!
I don't use pre-compiled libraries. I compile everything myself, because not only do the binaries that I compile need to be WinXP compatible, they need to work on old non-SSE2 cpus as well.

Quote:
Originally Posted by LoRd_MuldeR View Post
If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.
Yes, I understand I have to re-compile all dependency libraries in that case.

Quote:
Originally Posted by LoRd_MuldeR View Post
For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.
Which I do, as I'm using Zeranoe's "MingGW-w64 Build Script" after all.

Quote:
Originally Posted by LoRd_MuldeR View Post
But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64.
The reason why I'm compiling MinGW-w64 with pthreads-w32 (which is the default thread library in Zeranoe's "MingGW-w64 Build Script" anyway).

Thanks for your elaborate post, LoRd_MuldeR.
__________________
My hobby website
Reino is offline   Reply With Quote
Old 13th September 2021, 19:58   #46  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,225
Quote:
Originally Posted by Reino View Post
Which I assume is a cmake option?
It's an option for GCC. Or any compiler with GCC-compatible command-line syntax, such as Clang. You generally add this to the CFLAGS, or whatever is the equivalent in cmake.

Quote:
Originally Posted by Reino View Post
Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.
Don't know how this would save you from trouble.

If the code of the application (or its dependencies) that you are compiling uses some function from the Win32 API that was not yet available in Windows XP, then it won't be able to run on Windows XP – regardless of which version of MingGW-w64 you are using to build. Even setting _WIN32_WINNT to 0x0501 won't "magically" make the code run on Windows XP; this only causes the compilation to fail, if the code attempts to call a function that was unavailable in Windows XP.

Only way to get the application (or library) work on Windows XP will be to "patch" the actual program code in order to remove/replace any invocation of the "problematic" Win32 API functions...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 13th September 2021 at 20:10.
LoRd_MuldeR is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.