VLC for PowerPC: make a separate port or modify existing?

Sat Aug 5 13:20:42 UTC 2023

> 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.webuse at 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.had at 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.webuse at 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.had at 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.webuse at 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.
>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20230805/ddf7b637/attachment.htm>