mirror of
https://github.com/ultimatepp/ultimatepp.git
synced 2026-05-15 14:16:07 -06:00
[GH-ISSUE #277] Please unbreak Big-endian case #87
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/ultimatepp#87
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @barracuda156 on GitHub (Jun 6, 2025).
Original GitHub issue: https://github.com/ultimatepp/ultimatepp/issues/277
For no good reason, the build prohibits to build on a BE arch due to this:
7b291a1a5d/uppsrc/Core/config.h (L158-L160)It is okay not to guarantee official support and not to test it, but issuing a warning will be enough.
@barracuda156 commented on GitHub (Jun 6, 2025):
Broken by
02095b7f84And by
19dd6c72f1The first case is trivial to unbreak, the second
may need a bit of rewritingis also easy.@mirek-fidler commented on GitHub (Jun 10, 2025):
The problem is that the BE problem is not just in those 2 places. I have added that error because there are mutliple places though U++ where it would need fixing. We also require int to be at least 32 bit and do not support mixed endian either...
There really are only 2 extant architectures with BE (IBM mainframes and LEON Sparc for ESA). Chances that not supporting BE will reduce our userbase is infinitesimal.
@barracuda156 commented on GitHub (Jun 10, 2025):
powerpc is Big-endian on most platforms. (Recent CPUs are bi-endian, but not all platforms are.)
This should not be an issue, I do not think any 16-bit platforms are in use outside of museums.
Okay, but was it working earlier, was it never tested, or what was the status? These commits with adding errors are pretty recent.
By the way, if the question is to test the build, I can do that. (I may not be able to fix every instance of broken code, if it is there, but we can concentrate on core features and disable something not too important.)
@mirek-fidler commented on GitHub (Jun 10, 2025):
POWER PC ended 20 years ago. I really really doubt we need to support 2006
Macs. Besides, it would not run on that version of macos anyway.
BE was never ever tested. Some code (and I believe even some 3rd party
code) was written ignoring it.
There are many really important issues that require attention. BE is not
one of them. A lot of work, zero benefit.
If for some reason it became suddenly important, I can go back and
implement it. But I doubt it, LE is not going away.
(FIY, I am also going to clean GUI code from palette support and "mixed
backpaint" mode and other things).
On Tue, Jun 10, 2025 at 2:15 PM Sergey Fedorov @.***>
wrote:
@barracuda156 commented on GitHub (Jun 10, 2025):
Well, I meant inclusive of IBM Power, which are among the best cpus to this day. Power arch did not end, nor BE platforms are going away any soon either.
I do not expect anyone to be testing or specifically fixing the code for powerpc macOS, but there is nothing here in the code which would not work, AFAICT. Endianness is the only issue, and it is nothing specific to powerpc Macs.
GTK works (GTK4 does not work amazingly well in all cases, but still works fine in most; GTK3 works perfectly), the latest C++ is supported. Why wouldn’t it run.
@barracuda156 commented on GitHub (Jan 22, 2026):
@mirek-fidler Hi, was something addressed in recent commits?
@mirek-fidler commented on GitHub (Jan 22, 2026):
Nope. I am closing at something we are not going to resolve (general issues
cleanup).
Now I am sorry that we do not serve your use case well.
However, if you feel like BE is important for you, it should be trivial to
branch U++ and fix it (and keep up updated by merging master eventually).
Mirek
On Thu, Jan 22, 2026 at 11:30 AM Sergey Fedorov @.***>
wrote:
@barracuda156 commented on GitHub (Mar 21, 2026):
UPD. I got past the segfault.
@mirek-fidler Just in case, does this say something? I am not asking to debug this for me, but if you can say what is likely failing, that would be very helpful. (Feel free to ignore otherwise.)
Context: I got the build from source working on x86 and then got
bobcatterminal compiled against U++. Reproducing the same on powerpc broke down on this segfault.