> So you’re not getting any current version to build, but as I said, you might get some old version to build.
Just turn off ObjC garbage and build normally in C/C++ :) FreeBSD has it for 32-bit targets: https://github.com/freebsd/freebsd-ports/blob/main/multimedia/vlc/Makefile This will not require any extensive patching. What will need patching, will be mostly upstream bugs. As I noted above, I got issues due to endianness with VLC 2.2.8, so I do not make a claim that the video is gonna work correctly or – if not – that it is fixable. This I do not know. P. S. Tried now MPlayer, the build failed with some undeclared identifiers in libao2. Probably fixable. On Sat, Aug 5, 2023 at 2:26 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > > vlc is built against a cocoa interface, not qt, on macos. It has many HAVE_OSX > defines scattered thoroughout the code, that all assume macos technologies > for the pathways. It is currently written to support a floor sdk of 10.11. > Changing all that code to support old systems again is… unrealistic, shall > we say. > > So you’re not getting any current version to build, but as I said, you > might get some old version to build. I have an old version that works now > on older systems, of course :) It just can’t play much. > > But Mplayer is much more functional, which was my point. And older systems > are lucky to have that, as vlc and mpv have left them all behind, given > their full GUIs needing more current SDK features. > > A recent update to the mplayer-devel code broke <10.7 , but that looks > like an easy fix to me. > > > > > > On Aug 4, 2023, at 23:03, Sergey Fedorov <vital....@gmail.com> wrote: > > > > even if you find some old version that still builds on the ancient > systems ... pointlessly out of date. > > 2.2.8 builds, I think the latest should (either with restored Qt4 or > without Qt). The question is which works. > So far it seems that X11 video output works but has broken colors due to > never fixed upstream bugs in OpenGL or alike. > > For example, this was reported in 2016 and apparently still broken: > https://bugreports.qt.io/browse/QTBUG-56975 > > P. S. It is useful to have several players. From experience even on modern > Intel, none is perfectly reliable and some will be preferred to another > conditionally. > > On Sat, Aug 5, 2023 at 8:50 AM Ken Cunningham < > ken.cunningham.web...@gmail.com> wrote: > >> even if you find some old version that still builds on the ancient >> systems ... pointlessly out of date. >> >> yet MPlayer is right up to the minute, and worked very well even on Tiger >> PPC last I tried it. >> >> Anyway, play with VLC as you wish, of course. >> >> >> >> On Aug 4, 2023, at 5:26 PM, Sergey Fedorov <vital....@gmail.com> wrote: >> >> Don’t worry, I will not submit a PR for VLC unless it actually works with >> video. There is no point otherwise. >> >> If it does not, I just leave it. But for now it still makes sense to >> have an idea what to do with the port *IF* it works. >> >> On Sat, Aug 5, 2023 at 7:02 AM Ken Cunningham < >> ken.cunningham.web...@gmail.com> wrote: >> >>> For playing videos on older systems, I think MPlayer is the way to go. >>> >>> Give that a try if you haven't. >>> >>> Ken >>> >>> >>> On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote: >>> >>> I need an advice. >>> >>> We got VLC2 port (which is totally broken for all systems) and VLC port, >>> which installs pre-built binary. Neither supports PPC, obviously, and even >>> i386. >>> >>> Leaving the main VLC aside, VLC2 is already a mess and in the present >>> state is unusable for practical purposes. Rewriting the logic is doable (I >>> have done it locally, kind of), however I have few concerns here: >>> >>> 1. Given the complexity of the port, it may not be obvious for anyone >>> who might wish to update it in the future or fix something for Intel >>> systems, what has to be left untouched for PPC (assuming that testing for >>> PPC cannot be done due to lack of hardware). It is very easy to break the >>> build, I just now tried to enable a feature which looked harmless, and that >>> broke the build immediately. And we cannot really write passages of >>> explanations for every change or choice. >>> >>> 2. On the other hand, even though the port is currently broken for >>> Intel, my fixes might introduce some undesirable effects for it, unless of >>> course literally everything is put inside the guarding condition. But then >>> we have x2 more code in the port, which is already barely readable. >>> >>> For these reasons, it seems easier and safer to have a separate VLC-ppc >>> port: then I can work on it without bothering to match versions or to break >>> anything for someone, and at the same time be reasonably sure no one >>> accidentally breaks PPC build. >>> >>> However, we seldom make arch-specific ports, so I assume, it may not be >>> considered desirable. >>> >>> Which way should I go here? Ultimately I am fine with either option, but >>> it will save time to decide first rather than having to rewrite later >>> something completely. >>> >>> >>> P. S. Re status of the thing itself: >>> >>> Given that FreeBSD seems to build the current VLC 3.x for 32-bit archs, >>> including PPC (may be untested, but still), chances are it can be fixed. >>> However, support for Qt4 has to be restored or otherwise Qt should be >>> foregone completely. >>> >>> *Building* of VLC2 I have fixed for PPC tonight. It works in some >>> aspects (GUI is acceptably okay, audio output seems perfect), but video >>> either does not or works partly (I cannot tests all output modes right now >>> for technical reasons). >>> So it is not a matter of tomorrow’s PR yet, but if it works, it may work >>> rather soon. >>> >>> >>> >>> >>
