media-autobuild_suite
media-autobuild_suite copied to clipboard
m-ab-s
Dropping support of 32-bit build
Алексей @Alexpux 06:28 I will not provide 32 bit MSYS2-packages anymore since today
from gitter
Starting today, it seems that 32-bit packages will no longer be updated, thus it would be good to be able to drop 32-bit support soon.
Any comments/concerns @wiiaboo and @LigH-de (since you are the only one that I know compiles 32-bit)
I read this like there won't be msys32 anymore, but cross-compilation under msys64 may still be possible. That's fine for me as a buffer. But I do see that with the discontinuation of Windows 7, the market for 32-bit code vanishes, and when even cross-compiling is not possible anymore, I shall not cry but let old limits go...
I think it's more like the current mingw-w64-i686 packages will be frozen at their current state and none of those packages will receive any more updates, maybe not even bugfixes etc, so theoretically, cross-compilation will still be possible, just not supported
There are missundestanding. I will not update packages for 32-bit MSYS, not MINGW
I think it might be fine to reopen this since it might be a good time to revisit the question of dropping 32-bit compilation since currently both of the "official" builds listed on ffmpeg.org (gyan's, BtbN) does not distribute 32-bit builds, and also considering a lot of issues stem from 32-bit, and we have a lot of code specific to 32-bit, I think it might be better to drop it
I do want to get some other people's opinion on this though, emote with +1 for drop or -1 for no drop I guess, with comments for specific concerns or questions or arguments
pinging people who recently had issues with 32-bit builds (thus the only people I know who actually compile 32-bit, not for testing)
@Rollinnn @pat357 @kenichi512 @jlw4049 @Barough
I do compile for both targets as long as it is supported, knowing that a few people enjoy me still providing 32-bit builds now and then, where available. But I won't be the "last hope" for those. Might abstain from voting... not sure yet.
I've only had one request so far for 32-bit builds.
If someone is ready to build a redistributable 32-bit build once whenever a micro (or greater) release occurs, I would be willing to host it.
32bit dlls are still used for virtualdub's ffmpeg plugin - it's downloaded quite a lot
@GyanD if it's the compiling thats a problem I can do that , it doesn't take long - could even schedule the pc to do it daily while im at work Not sure how you'd do an ffmpeg release version as mab just pulls the latest? So far the only problem has been the compile errors with strncpy_s and rust that has meant more fails that sucesses ;-)
For me this is fine. Today's world is only 64bit. Don't need 32bit versions of the suite and the software it compiles.
@dloneranger You would modify build/media-suite_compile.sh to pull from ffmpeg repo from a release branch. It's a small change on one line.
@GyanD well, if 32bit stays (hope so, most virtualdub plugins are 32bit) I can do that Probably better to wait to see what happens here and then feel free to email me [email protected] if you'd like me to do the building
I want 32bit to stay as long as it's possible. I know some that enjoy that im still compiling 32bit encoders.
If everything rust is broken in 32-bit, then nothing rust is compiled for 32-bit, simple. If any library is only broken in 32-bit, disable it indefinitely.
If people need that rust app/library in 32-bit, let them waste time making it work again.
Considering how this repo purpose is to build a variety of native Windows binaries for a bunch of programs, and knowing how the whole Windows legacy ecosystem is much more complex than people might want to admit it, I'd say keep the 32bit framework/toolchain for now, but only if it doesn't incur a costly maintainance burden.
An alternative I was thinking about is essentially forking this repo, but making that fork 32-bit only and stripping out a lot of things so it only compiles ffmpeg and making that fork essentially maintenance mode only. That way this main mabs can be 64-bit only, and that fork will be 32-bit only, but I am not sure about how much effort that will be as well.
Well, it'd be almost the same effort to keep 32-bit but strongly discourage it.
I guess since it's been 1 week, I will start first making sure that 32-bit compilation for both clang and gcc at least works (probably not going to test if all of the resulting binaries do work though), then maybe tag the commit, and then work on removing 32-bit support from the main repo, I might consider making a separate fork or repo based on that tag and strip pretty much everything except 32-bit ffmpeg and libs and then put that on maintenance mode. But for the most part, those who still might want 32-bit compilation can pin their suite to that commit, I hope.
I often compile 32bit mencoder/mplayer/ffmpeg :) Mainly to handle 32bit Avisynth scripts and DVDs So it would be nice if 32bit would still be supported.
Well, we still have a bit of time before anything major happens, right now I'm first trying to completely make 32-bit compilation work including vlc, currently waiting on msys2 to update their headers-git package to the latest for qtdeclarative building
Just a quick mention as it's quite pertinent to this topic: building only 64bit ffmpeg with OpenCL enabled currently fails. I do realize OpenCL-support isn't exactly high priority, but that's still one thing that could warrant looking into, once 32bit support is dropped.
I guess while trying to fix 32-bit and 64-bit compilation with gcc and clang, I can try to test as many libraries for ffmpeg as well
Just a quick mention as it's quite pertinent to this topic: building only 64bit ffmpeg with OpenCL enabled currently fails. I do realize OpenCL-support isn't exactly high priority, but that's still one thing that could warrant looking into, once 32bit support is dropped.
could you perhaps elaborate on your issue of ffmpeg and opencl 64-bit? I still haven't run into it
I think despite the excellent improvements in hardware world, Its still essential to keep supporting 32bit system because the number of users with 32 bit devices is not low. These difficulties seems come from one of the ffmpeg developers mistake that they tried to put anything together in one package. There are various codecs/licenses/build environments/tools/compatibility issues and no one except a few experts are able to compile it for windows. This script couldn't help either. After all the ffmpeg power and ability in doing advanced coding stuffs is unquestionable but I feel they need to break their library into the small parts and release separate guide in-order to compile/use each of them.
I think despite the excellent improvements in hardware world, Its still essential to keep supporting 32bit system because the number of users with 32 bit devices is not low. These difficulties seems come from one of the ffmpeg developers mistake that they tried to put anything together in one package
Uh, first you're talking about one thing, then about a completely different thing. How is difficulties with compiling ffmpeg related to people using or not using 32bit systems?