[GH-ISSUE #277] Please unbreak Big-endian case #87

Closed
opened 2026-05-05 03:38:47 -06:00 by gitea-mirror · 8 comments
Owner

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.

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: https://github.com/ultimatepp/ultimatepp/blob/7b291a1a5d3cd6935f5c159716f60d08f75e162c/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.
Author
Owner

@barracuda156 commented on GitHub (Jun 6, 2025):

Broken by 02095b7f84

And by 19dd6c72f1

The first case is trivial to unbreak, the second may need a bit of rewriting is also easy.

<!-- gh-comment-id:2948845550 --> @barracuda156 commented on GitHub (Jun 6, 2025): Broken by https://github.com/ultimatepp/ultimatepp/commit/02095b7f84e22e5d85c04a2a090a2ba1282fecd1 And by https://github.com/ultimatepp/ultimatepp/commit/19dd6c72f10b0ed55f0d6a4f15744de1f2aca481 The first case is trivial to unbreak, the second <s>may need a bit of rewriting</s> is also easy.
Author
Owner

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

<!-- gh-comment-id:2958407020 --> @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.
Author
Owner

@barracuda156 commented on GitHub (Jun 10, 2025):

There really are only 2 extant architectures with BE (IBM mainframes and LEON Sparc for ESA).

powerpc is Big-endian on most platforms. (Recent CPUs are bi-endian, but not all platforms are.)

We also require int to be at least 32 bit

This should not be an issue, I do not think any 16-bit platforms are in use outside of museums.

I have added that error because there are mutliple places though U++ where it would need fixing.

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

<!-- gh-comment-id:2958976470 --> @barracuda156 commented on GitHub (Jun 10, 2025): > There really are only 2 extant architectures with BE (IBM mainframes and LEON Sparc for ESA). powerpc is Big-endian on most platforms. (Recent CPUs are bi-endian, but not all platforms are.) > We also require int to be at least 32 bit This should not be an issue, I do not think any 16-bit platforms are in use outside of museums. > I have added that error because there are mutliple places though U++ where it would need fixing. 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.)
Author
Owner

@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 left a comment (ultimatepp/ultimatepp#277)
https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-2958976470

There really are only 2 extant architectures with BE (IBM mainframes and
LEON Sparc for ESA).

powerpc is Big-endian on most platforms. (Recent CPUs are bi-endian, but
not all platforms are.)

We also require int to be at least 32 bit

This should not be an issue, I do not think any 16-bit platforms are in
use outside of museums.

I have added that error because there are mutliple places though U++ where
it would need fixing.

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


Reply to this email directly, view it on GitHub
https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-2958976470,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARH236LO22WJFKXKKVY37L3C3D7NAVCNFSM6AAAAAB6XXIVZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJYHE3TMNBXGA
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:2959046902 --> @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* left a comment (ultimatepp/ultimatepp#277) > <https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-2958976470> > > There really are only 2 extant architectures with BE (IBM mainframes and > LEON Sparc for ESA). > > powerpc is Big-endian on most platforms. (Recent CPUs are bi-endian, but > not all platforms are.) > > We also require int to be at least 32 bit > > This should not be an issue, I do not think any 16-bit platforms are in > use outside of museums. > > I have added that error because there are mutliple places though U++ where > it would need fixing. > > 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.) > > — > Reply to this email directly, view it on GitHub > <https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-2958976470>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AARH236LO22WJFKXKKVY37L3C3D7NAVCNFSM6AAAAAB6XXIVZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJYHE3TMNBXGA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
Author
Owner

@barracuda156 commented on GitHub (Jun 10, 2025):

POWER PC ended 20 years ago.

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 really really doubt we need to support 2006 Macs. Besides, it would not run on that version of macos anyway.

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.

<!-- gh-comment-id:2959131580 --> @barracuda156 commented on GitHub (Jun 10, 2025): > POWER PC ended 20 years ago. 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 really really doubt we need to support 2006 Macs. Besides, it would not run on that version of macos anyway. 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.
Author
Owner

@barracuda156 commented on GitHub (Jan 22, 2026):

@mirek-fidler Hi, was something addressed in recent commits?

<!-- gh-comment-id:3783657010 --> @barracuda156 commented on GitHub (Jan 22, 2026): @mirek-fidler Hi, was something addressed in recent commits?
Author
Owner

@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 left a comment (ultimatepp/ultimatepp#277)
https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-3783657010

@mirek-fidler https://github.com/mirek-fidler Hi, was something
addressed in recent commits?


Reply to this email directly, view it on GitHub
https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-3783657010,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARH237PTES6T5SJVS6KGJT4ICRENAVCNFSM6AAAAAB6XXIVZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBTGY2TOMBRGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

<!-- gh-comment-id:3783685771 --> @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* left a comment (ultimatepp/ultimatepp#277) > <https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-3783657010> > > @mirek-fidler <https://github.com/mirek-fidler> Hi, was something > addressed in recent commits? > > — > Reply to this email directly, view it on GitHub > <https://github.com/ultimatepp/ultimatepp/issues/277#issuecomment-3783657010>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AARH237PTES6T5SJVS6KGJT4ICRENAVCNFSM6AAAAAB6XXIVZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBTGY2TOMBRGA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >
Author
Owner

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

make: Leaving directory `/opt/local/var/macports/build/ultimatepp-28bdc723/work/ultimatepp-2025.1.1'
Command failed: CXX=/opt/local/bin/g++-mp-14 ./umk ./uppsrc ide GCC -brs ./theide
Killed by signal: 10
Error: Failed to build ultimatepp: command execution failed

(gdb) run ./uppsrc ide GCC -brs ./theide
Starting program: /opt/local/var/macports/build/ultimatepp-28bdc723/work/ultimatepp-2025.1.1/umk ./uppsrc ide GCC -brs ./theide
Reading symbols for shared libraries .+++++++++.................................................................................................. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000069
0x002c67b8 in Upp::String0::LSet ()
(gdb) bt full
#0  0x002c67b8 in Upp::String0::LSet ()
No symbol table info available.
#1  0x0032946c in Upp::Value::operator= ()
No symbol table info available.
#2  0x0037e168 in Upp::LanguageInfo::Set ()
No symbol table info available.
#3  0x0037f388 in Upp::GetLanguageInfo ()
No symbol table info available.
#4  0x0037f5ec in Upp::SyncLngInfo__ ()
No symbol table info available.
#5  0x00378b4c in Upp::SetCurrentLanguage ()
No symbol table info available.
#6  0x8fe107a4 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
No symbol table info available.
#7  0x8fe0e97c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
No symbol table info available.
#8  0x8fe0ea58 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
No symbol table info available.
#9  0x8fe02918 in __dyld__ZN4dyld24initializeMainExecutableEv ()
No symbol table info available.
#10 0x8fe07a8c in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
No symbol table info available.
#11 0x8fe0174c in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
No symbol table info available.
#12 0x8fe01064 in __dyld__dyld_start ()
No symbol table info available.
(gdb) info registers
r0             0x2c677c	2910076
r1             0xbfffd370	3221214064
r2             0x65	101
r3             0x3b0b164	61911396
r4             0x48	72
r5             0x458	1112
r6             0x4801200	75502080
r7             0x3	3
r8             0x4800200	75497984
r9             0x48001e0	75497952
r10            0xf	15
r11            0xbfffd370	3221214064
r12            0x91a19a20	2443287072
r13            0x8fe3ec28	2414079016
r14            0x1c2c	7212
r15            0x0	0
r16            0x548e78	5541496
r17            0x548e08	5541384
r18            0x548e38	5541432
r19            0x548e10	5541392
r20            0x548e28	5541416
r21            0x6e	110
r22            0x48011d0	75502032
r23            0x4008e24	67145252
r24            0x53	83
r25            0x55	85
r26            0xbfffd430	3221214256
r27            0x4007ee4	67141348
r28            0xbfffd3b0	3221214128
r29            0x4007c04	67140612
r30            0xbfffd420	3221214240
r31            0x2c6704	2909956
pc             0x2c67b8	2910136
ps             0x100000000200d030	1152921504640454704
cr             0x44000201	1140851201
lr             0x2c677c	2910076
ctr            0x91a19a20	2443287072
xer            0x0	0
mq             0x0	0
fpscr          0x82000000	2181038080
vscr           0x10000	65536
vrsave         0x0	0

Context: I got the build from source working on x86 and then got bobcat terminal compiled against U++. Reproducing the same on powerpc broke down on this segfault.

<!-- gh-comment-id:4102982744 --> @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.) ``` make: Leaving directory `/opt/local/var/macports/build/ultimatepp-28bdc723/work/ultimatepp-2025.1.1' Command failed: CXX=/opt/local/bin/g++-mp-14 ./umk ./uppsrc ide GCC -brs ./theide Killed by signal: 10 Error: Failed to build ultimatepp: command execution failed (gdb) run ./uppsrc ide GCC -brs ./theide Starting program: /opt/local/var/macports/build/ultimatepp-28bdc723/work/ultimatepp-2025.1.1/umk ./uppsrc ide GCC -brs ./theide Reading symbols for shared libraries .+++++++++.................................................................................................. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000069 0x002c67b8 in Upp::String0::LSet () (gdb) bt full #0 0x002c67b8 in Upp::String0::LSet () No symbol table info available. #1 0x0032946c in Upp::Value::operator= () No symbol table info available. #2 0x0037e168 in Upp::LanguageInfo::Set () No symbol table info available. #3 0x0037f388 in Upp::GetLanguageInfo () No symbol table info available. #4 0x0037f5ec in Upp::SyncLngInfo__ () No symbol table info available. #5 0x00378b4c in Upp::SetCurrentLanguage () No symbol table info available. #6 0x8fe107a4 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () No symbol table info available. #7 0x8fe0e97c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () No symbol table info available. #8 0x8fe0ea58 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE () No symbol table info available. #9 0x8fe02918 in __dyld__ZN4dyld24initializeMainExecutableEv () No symbol table info available. #10 0x8fe07a8c in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ () No symbol table info available. #11 0x8fe0174c in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl () No symbol table info available. #12 0x8fe01064 in __dyld__dyld_start () No symbol table info available. (gdb) info registers r0 0x2c677c 2910076 r1 0xbfffd370 3221214064 r2 0x65 101 r3 0x3b0b164 61911396 r4 0x48 72 r5 0x458 1112 r6 0x4801200 75502080 r7 0x3 3 r8 0x4800200 75497984 r9 0x48001e0 75497952 r10 0xf 15 r11 0xbfffd370 3221214064 r12 0x91a19a20 2443287072 r13 0x8fe3ec28 2414079016 r14 0x1c2c 7212 r15 0x0 0 r16 0x548e78 5541496 r17 0x548e08 5541384 r18 0x548e38 5541432 r19 0x548e10 5541392 r20 0x548e28 5541416 r21 0x6e 110 r22 0x48011d0 75502032 r23 0x4008e24 67145252 r24 0x53 83 r25 0x55 85 r26 0xbfffd430 3221214256 r27 0x4007ee4 67141348 r28 0xbfffd3b0 3221214128 r29 0x4007c04 67140612 r30 0xbfffd420 3221214240 r31 0x2c6704 2909956 pc 0x2c67b8 2910136 ps 0x100000000200d030 1152921504640454704 cr 0x44000201 1140851201 lr 0x2c677c 2910076 ctr 0x91a19a20 2443287072 xer 0x0 0 mq 0x0 0 fpscr 0x82000000 2181038080 vscr 0x10000 65536 vrsave 0x0 0 ``` Context: I got the build from source working on x86 and then got `bobcat` terminal compiled against U++. Reproducing the same on powerpc broke down on this segfault.
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/ultimatepp#87
No description provided.