Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dropping support of 32-bit build #1660

Open
1480c1 opened this issue May 18, 2020 · 52 comments
Open

Dropping support of 32-bit build #1660

1480c1 opened this issue May 18, 2020 · 52 comments
Labels
discussion Maybe related to any meta stuff about the suite

Comments

@1480c1
Copy link
Member

1480c1 commented May 18, 2020

Алексей @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)

@LigH-de
Copy link
Contributor

LigH-de commented May 18, 2020

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...

@1480c1
Copy link
Member Author

1480c1 commented May 18, 2020

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

@Alexpux
Copy link

Alexpux commented May 18, 2020

There are missundestanding. I will not update packages for 32-bit MSYS, not MINGW

@1480c1
Copy link
Member Author

1480c1 commented May 18, 2020

Ahh, I see, nevermind then

@1480c1 1480c1 closed this as completed May 18, 2020
@1480c1
Copy link
Member Author

1480c1 commented May 18, 2020

I guess I still need to update to prevent using a msys32 host

@wiiaboo
Copy link
Member

wiiaboo commented May 19, 2020

That's great news.

@1480c1
Copy link
Member Author

1480c1 commented Sep 28, 2020

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

@1480c1 1480c1 reopened this Sep 28, 2020
@1480c1
Copy link
Member Author

1480c1 commented Sep 28, 2020

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

@1480c1 1480c1 pinned this issue Sep 28, 2020
@1480c1
Copy link
Member Author

1480c1 commented Sep 28, 2020

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

@LigH-de
Copy link
Contributor

LigH-de commented Sep 28, 2020

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.

@GyanD
Copy link
Contributor

GyanD commented Sep 28, 2020

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.

@dloneranger
Copy link

32bit dlls are still used for virtualdub's ffmpeg plugin - it's downloaded quite a lot

@jessielw
Copy link

I do not not require 32 bit

@dloneranger
Copy link

@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 ;-)

@moisespr123
Copy link
Contributor

For me this is fine. Today's world is only 64bit. Don't need 32bit versions of the suite and the software it compiles.

@GyanD
Copy link
Contributor

GyanD commented Sep 28, 2020

@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.

@dloneranger
Copy link

@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

@Barough
Copy link

Barough commented Sep 28, 2020

I want 32bit to stay as long as it's possible. I know some that enjoy that im still compiling 32bit encoders.

@wiiaboo
Copy link
Member

wiiaboo commented Sep 28, 2020

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.

@garoto
Copy link

garoto commented Sep 28, 2020

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.

@1480c1
Copy link
Member Author

1480c1 commented Sep 28, 2020

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.

@wiiaboo
Copy link
Member

wiiaboo commented Sep 28, 2020

Well, it'd be almost the same effort to keep 32-bit but strongly discourage it.

@1480c1
Copy link
Member Author

1480c1 commented Oct 5, 2020

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.

@Selur
Copy link

Selur commented Oct 13, 2020

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.

@1480c1
Copy link
Member Author

1480c1 commented Oct 13, 2020

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

@1480c1 1480c1 added the discussion Maybe related to any meta stuff about the suite label Oct 21, 2020
@WereCatf
Copy link

WereCatf commented Dec 2, 2020

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.

@1480c1
Copy link
Member Author

1480c1 commented Dec 2, 2020

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

@1480c1
Copy link
Member Author

1480c1 commented Dec 3, 2020

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

@WereCatf
Copy link

WereCatf commented Dec 5, 2020

@1480c1 Nevermind, I'm a dumbass.

@WereCatf
Copy link

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?

@viliml
Copy link

viliml commented Feb 17, 2021

I guess Delphi-Coder's point is that making mabs 64-bit only would sadden people on 32-bit systems because they would lose the simple way to compile ffmpeg.

@ggarra13
Copy link

ggarra13 commented Jun 9, 2021

-1. Please keep 32bit support.

@softworkz
Copy link
Contributor

About 10% of our users are still downloading the 32bit package of our Windows application.
If 32bit build support would be removed, we'd have to stop using m-ab-s altogether and cross-compile on Linux instead.

@GTANAdam
Copy link

GTANAdam commented Sep 4, 2021

32bit should be kept for some legacy purposes, removing it should cause lots of issues to lots of users

@ultrasound1372
Copy link

At least keep 32-bit build on 64-bit systems, the resulting FFmpeg is being brought into foobar2000 to support more codecs and foobar2000 is still 32-bit only.

@Rollinnn
Copy link

At least keep 32-bit build on 64-bit systems, the resulting FFmpeg is being brought into foobar2000 to support more codecs and foobar2000 is still 32-bit only.

If you are talking about foo_input_ffmpeg, it can use 64-bit ffmpeg. On 64-bit Windows only , of course.

@ultrasound1372
Copy link

ultrasound1372 commented Feb 23, 2022

That and foo_youtube, which uses the AV libraries directly.

@1480c1
Copy link
Member Author

1480c1 commented Feb 28, 2022

For the people who still use 32-bit libraries etc, can you list which libraries and executables you actually use/need?

@Selur
Copy link

Selur commented Feb 28, 2022

Sure. :)
I frequently use use: mplayer,mencoder, ffmpeg.

@1480c1
Copy link
Member Author

1480c1 commented Feb 28, 2022

mplayer,mencoder, ffmpeg.

For those, do you know which external libraries you use for them? Or is it just "all"?

@Selur
Copy link

Selur commented Feb 28, 2022

Personally I only need the 32bit versions for handling 32bit Avisynth and mencoder&mplayer for their 32bit vfw interface to handle some old usually propriatary legacy formats libav can't handle. (For anything else I use the 64bit versions.)

@softworkz
Copy link
Contributor

Hi,

we are still doing 32bit builds with each release and each beta and there's still a significant share of users who are downloading the 32bit Windows packages (haven't drilled down on the reasons).

In our case it's all ffmpeg executables (with most of the libs) but none of any of the other executables.

BTW, thanks a lot for maintaining this project!

Best wishes,
softworkz

@ultrasound1372
Copy link

I use all FFmpeg shared libs and MPV integrated with a few components in foobar2000, requiring they all be 32-bit. I do not use the 32-bit version of any of the static command line executables. My build environment is option 3 with minor changes, can send you my options.txt if necessary. The foo_youtube component also has the ability to specify an external libcurl, which I assume also has to be 32-bit, but I don't personally use that option. Furthermore it supports integration of madVR, VSFilter, and LAV Filters libraries. Those, however, I get from other places since the suite doesn't build them, and I doubt it needs to.

@Maypeur
Copy link

Maypeur commented Oct 22, 2022

Please no, keep alive this 32b version i link it in all my program !
Anyway, thanks for this usefull tool !

@ultrasound1372
Copy link

It turns out VGMStream includes configuration files for a custom FFmpeg build via this suite, and it is primarily compiled as 32-bit for all of its media player plug-ins.

@maxiuca
Copy link

maxiuca commented Dec 17, 2022

I'm also still using 32bit builds for some specific tasks, and m-ab-s has been extremely useful for me for the last 2 years because I can get 32b versions of apps built that aren't available to download anywhere.

@suphamster
Copy link

Looks like support for 32bit already dropped this year coz it doesn't wants to compile throwing error similar like in ancient issue there https://trac.ffmpeg.org/ticket/3177

@LigH-de
Copy link
Contributor

LigH-de commented Jan 6, 2023

Which support of what module exactly, @suphamster ? This issue is about the general support of a separate MinGW32 cross-compilation stage in m-ab-s, not in the sources of ffmpeg or any linked codec.

@suphamster
Copy link

Which support of what module exactly, @suphamster ? This issue is about the general support of a separate MinGW32 cross-compilation stage in m-ab-s, not in the sources of ffmpeg or any linked codec.
Yeah, looks like I chose wrong topic and my error exactly same as described in my link.
┌ ffmpeg git ............................................ [Files missing] ├ Changing options to comply to nonfree... ├ Compiling static FFmpeg... ├ Running configure... ├ Running make... Likely error (tail of the failed operation logfile): inlined from 'get_cabac' at src/libavcodec/cabac_functions.h:145:12, inlined from 'decode_cabac_mb_intra4x4_pred_mode' at src/libavcodec/h264_cabac.c:1377:9, inlined from 'ff_h264_decode_mb_cabac' at src/libavcodec/h264_cabac.c:2081:32: src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints 199 | __asm__ volatile( | ^~~~~~~ src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints make: *** [/build/ffmpeg-git/ffbuild/common.mak:81: libavcodec/h264_cabac.o] Error 1

@LigH-de
Copy link
Contributor

LigH-de commented Jan 6, 2023

That looks specific to the CABAC decoder in a libavcodec H.264 codec, in the ffmpeg sources.

@suphamster
Copy link

That looks specific to the CABAC decoder in a libavcodec H.264 codec, in the ffmpeg sources.

But 64bit version compiles fine with same settings so I thought that it concerns dropped support...

@LigH-de
Copy link
Contributor

LigH-de commented Jan 6, 2023

You are still in the wrong thread.

This thread is related to the development of the media-autobuild suite. We are not ffmpeg developers. Even if the ffmpeg team dropped support for 32-bit code (which I would doubt a lot), the suite can still compile many other codecs, also as separate executables, independent of ffmpeg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Maybe related to any meta stuff about the suite
Projects
None yet
Development

No branches or pull requests