Building for macOS PowerPC #2
Comments
|
It builds with GCC 11/12 PowerPC, but it crashes due to missing AutoRelease pool during startup. I plan to work on it when I have some time, but been busy with other stuff. I imported a bunch of stuff from TenFourFox, but not JIT (yet). Had a bit of trouble tracking down the crash though since the debugger does not give me useful information. |
|
@dbsoft Awesome, let me try that. Two quick questions:
|
|
Well I haven't built it in about a month, but the patches that allowed it to compile a month ago were merged into master... so unless something in the past month broke it ... it should still build... The PowerMac is offline right now, I'll boot it up later today (have a busy day today) and I'll post the mozconfig I used. Edit: Yesterday turned out to be a mess... didn't get around to it... will get it done today instead. |
|
Greatly appreciated, thanks. UPD. Just ping me here, and I will try running the build. (Do you use TFF way of building or Arctic Fox way of building? I mean, the initial build command.) |
|
This is the mozconfig I am using for testing purposes, I had disabled optiizations and stripping to try and debug it, but that did not really help. It takes like 16 hours to do a full build on my Powermac G5: Using the strip7 that was used for TenFourFox. I'll need to package up some MacOS 10.5 compatible branding since what I typically use does not work properly on 10.5. (In the meantime you can use the unofficial branding). Generally speaking the instructions here apply: https://dbsoft.org/whitestar-build-mac.php With some minor changes... use 10.5 SDK, jemalloc is not supported on 10.5 so disable that... JPEG-XL should theoretically work, but I have it disabled to reduce the build time. Not sure why I have AV1 disabled, might also be to reduce build times. Apple media is not supported on 10.5 so I added an option to disable that. |
|
Thank you very much!
Oh wow, that sounds like a lot longer than TenFourFox. Which G5 is that?
I will give it a try against 10.6 first (10A190, not Rosetta). My 10.5 setup is dead at the moment, since I nuked libgcc when trying to fix building of ppc+ppc64 :) P. S. It’s great that the modern gcc can be used with it. Resorting to archaic versions was painful with TFF. |
|
1.6ghz PowerMac7,2 This was the pull where I added the support: I tried to make sure I put everything in an #ifdef for the appropriate SDK versions, but some I was not absolutely certain about so... it only for sure works on the 10.5 SDK. |
|
@dbsoft I have just moved your unofficial folder to the location the build complained about, hopefully that gonna work. Build has commenced. |
|
Ah yeah, there will be issues with 10.6 SDK: I think it will be pretty much the same sequence of errors which I began fixing for Arctic Fox, more or less. Perhaps I can build against 10.5.8 SDK, which should bypass a need for per-case fixups, but as we know, that should produce a dead binary :) |
To be honest, I think literally nobody is certain here, since no 10.6 SDK is “standard” for PowerPC, including the released 10.6.8 with Rosetta, and of course those early developer ones which still supported PPC natively. To get a “standard” 10.6 on PowerPC, we will have to rebuild the system from sources, or at least those components which lack ppc slices in 10.6.8. I am not sure all needed sources are even available and whether something meaningful can be achieved with what we got. To make things worse, there is no documentation, AFAIK, which would describe the procedure, and existing info here-and-there is inaccurate or incomplete. And Darwinbuild is broken. At the same time potentially even a handicapped 10.6 is better (on 32-bit) than any 10.5, and some stuff works there which does not on the latter. |
The comment to the code: Sure enough, padding is wrong. |
|
What is interesting is that the referred chunk specifically excludes Darwin ppc here: Possibly, it was added as a hack around a bug in GCC related to structure packing. The bug has been fixed in gcc13, as I recall. Which would explain why it did not fail for you with gcc12. Resumed the build after removing ppc clause, let's see how far it proceeds. |
|
So apparently indeed, that assumption is wrong for gcc13, the build went a bit further, but then failed on this: I guess, this is the fix: |
|
And it claims to have succeeded: |
|
It did produce something which looks like an app, but:
|
|
There is some issue with stripping, and it is something I expected on 10.6: This is with a regular |
I was confused why I needed it... to get it to build with GCC 12.3 if it is in fact a packing bug that would explain it... just remove that one. I thought I changed the Info.plist to be 10.5 in my White Star repository... but I guess it is something I didn't actually commit: |
|
@dbsoft For the reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044 (I am not sure it is related, but it looks it may be). |
|
Rebuilt again, no errors during the build (two patches applies), strip fails with strip7: |
|
Okay, I got your result, I guess. It starts now after fixing plists, but freezes really badly: |
|
Well yours might actually dong slightly better than mine, since mine aborts due to a missing AutoRelease pool....but we are clearly at a similar place... building but something isn't quite right.... going to need some debugging, but I have just been busy with other things. So this experiment has been on the back burner.... I'll try to build a GCC with the packing patch and see if I can get it to where yours is.... but this is going to be slow going on my end. |
I can share portfiles if it makes life a bit easier. A sensible thing to try would be building the browser for |
|
Well I'd accept the port file, but I might just apply the patch to my tree so I don't have to wait for a full rebuild of GCC. |
|
@dbsoft Ah yeah, if it is set up this way, it certainly makes sense. P. S. By the way, if you do not already, use Iain’s branches for PowerPC. |
Looks like autorelease has just a wrong syntax. Dwarf error is something which feels vaguely familiar, but I can't recall immediately where I saw it. |
|
|
|
Very strange, never seen that before... If you are having issues with stripping... you can add these options: Probably will trigger a rebuild though. :( |
|
Yeah, I remembered about install-strip, after the second rebuild was complete, and quite pointlessly it indeed triggers the rebuild even if mozconfig is edited directly (and portfile untouched), so I left it at that until tomorrow. Anyway it is worth looking through the code to see what is going wrong and hopefully fix it for 10.6 SDK. Could you confirm if AltiVec fix is at least harmless on your setup? |
|
I do not recall any issues with strip aside of Mozilla-based browsers, no idea what is so special about them which a) justifies having a dedicated hacked version of strip incompatible with anything else and b) causes stripping to fail on 10.6. |
Not sure what you mean by this? |
I think you are misunderstanding what he is talking about there. So... consider... the Mach-O loader, to support PPC (32bit)... there are various CPU subtypes... G3,G4,G5(running 32bit) .... however for PPC64 there is only G5... so there is no need for a subtype. Does that make sense? There is no PPC64 G5 subtype because it is the only processor to support it... if you are on Mac running PPC64 it is a G5, end of story. If you are on Mac running PPC(32) ...it could be one of many processors and thus you need the subtype to know which is which. |
I recall Iain saying explicitly elsewhere that when compiling for 64-bit only |
Again, that may be for the same reason I just explained. PPC64 on Darwin is implicitly ppc970 (G5) ... since it is the only processor supported in 64bit mode. the ppc970 would only matter in 32bit mode. Since that is the only mode where CPU variants exist. |
After getting the same with |
|
And now we got something more meaningful with GDB: |
|
So something broken here, it seems: Endianness, ppc-specific hacks :) |
|
I see that chunk comes from TFF: https://github.com/classilla/tenfourfox/blob/656875dfebe724c31896e3073780638e2c213f81/gfx/thebes/gfxMacPlatformFontList.mm#L472-L523 And TFF is known to work fine. But, do we know this works with 10.5 SDK? And do we know if specific code is compatible with related code in Palemoon? |
Oh I'll give that a try, I was looking for an updated gdb.
That is code I imported from TenFourFox with that big endian patch.... obviously all of that code is untested in UXP since I was crashing before I could get to it. |
|
Crash log from the OS: (P. S. Just in case, it says whitestar-orig in the log, that is because I tried to use a wrapper alike to what legacy-support does to isolate a binary from a wrong libstdc++, but here it does not seem to change anything.) |
|
If I can get the debugger you referenced working, I will be able to get some serious work done on this soon. |
|
@dbsoft I think the current version of |
|
gdb-apple failed to build.... Will have to look at it tomorrow. Edit: Well I just commented out all references to MH_KEXT_BUNDLE in the 3 switches... then it successfully compiled: Attempting to run the binary gives this:
Edit 2: Scratch that I think I got it working, while I got a privilege escalation dialog, it seems to have failed to elevate it... I did "sudo gdb-apple" instead and it seems to be working. |
|
@evanmiller Evan, could you please take a look? We really need this working now. |
TFF (and InterWebPPC) will not build with the 10.5 SDK. It can be built on 10.5, but it must use the 10.4 SDK.
It will work fine. It just builds a “generic” binary that will run on G3/G4/G5 machines. I’ve built all 3 versions multiple times, and to be honest the G3 version feels more responsive than the “optimized” G4 and G5 builds. The only reason i mentioned it was to see if you’d have better luck with it as it disables altivec and any 64bit code. If you can get the generic G3 version running it might help narrow down any G4/G5 specific issues if there indeed happens to be any. |
|
Well gdb-apple is kind of hobbled, it errors out with any commands that control the program: next, step, cont .... however it is giving me enough information to get an idea of what is going on so... probably will be able to make some progress. |
|
@dbsoft Which version did you install? While I have current one installed on 10.5 and 10.6.8, I think I never used it; on 10a190 I have the previous version which I do use, and it seems pretty functional. Having said that, I am a very beginner with GDB and only did some basic stuff. |
|
@wicknix What I meant is whether the specific portion of code is compatible with 10.5 SDK, because for us here it matters, and if TFF hacks are specific to either Tiger or archaic GCC, they must be dropped. My suggestion is to restrict testing and work to 10.5 mostly (and I can do 10.6 ppc part on my end to supplement that), to the modern GCC (drop 4.8 and even 7.5.0) and to G4/G5. If anything, this minimizes the work a bit, and we got limited resources. It will likely result in a better outcome too, since bugs have been fixed in new GCCs and 10.5 SDK as compared to 10.4. |
|
@dbsoft By the way, there was a discussion about ppc64, may be of interest for us if we consider supporting it: classilla/tenfourfox#655 |
|
Okay, so the failure is because the MacSurface library requires and will abort if it isn't able to load a few libraries. TenFourFox uses the old "CoreGraphics" back-end... (although the name is a bit of a misnomer, since it isn't the "CoreGraphics.framework" that the MacSurface library uses) So to get things working again I'll probably have to resurrect the old backend. https://bugzilla.mozilla.org/show_bug.cgi?id=1258751 Also need to put this code back in conditionally so popups/panels still work: https://bugzilla.mozilla.org/show_bug.cgi?id=1274720 This was removed right before the UXP fork point, so it should be trivial to readd support.
Doesn't seem particularly helpful, I really don't think 64bit mode for this is going to be in my scope. If you want to separately work on it that is great.... I'd love to have. a 64bit version... but too much work for too little reward for me.
Whatever MacPorts tried to install, I pasted the version banner it posts when starting up in that earlier comment. |
Great that you tracked the problem. Will rebuild once you commit the fix.
This is not in priority list at all. I may try some time, provided we get 32-bit versions actually working first.
Ah, it was in edit, so GitHub mobile did not show me it. Got it. |
|
Just wanted to let you know that I had a death in the family, and I may not have time to put into this for a few weeks. I had planned on spending my spare time on it this week, but with the death that will be consumed with funeral arrangements. Will post an update here after I get the changes done. |
Sorry for your loss. Will wait until you are able to get back to this. |
|
Created a new branch for the fixes... part 1 removes the structure packing work-around, adds the altivec fix and restores the old 10.5 compatible GFX backend. https://repo.palemoon.org/dbsoft/UXP/src/branch/macppc-fixes Getting a null pointer de-reference in the font code which I'll fix in part 2 coming soon. https://gist.github.com/dbsoft/fdeb748d99c5ca0a9286080a87e06c23 Edit: Just an observation, after the changes... I landed at the same font crash you did ( which kind of appears to be overrunning the font directory cache buffer). So it looks kind of like PPC 10.6 has what is needed to run the Skia backend.... but not 10.5, it requires the CoreGraphics backend. I do not have 10.6 PPC installed.. so I can't verify that, but if 10.6 has all the frameworks required for the Skia backend it would explain why yours got to the font crash before mine did. The question is why would TenFourFox/InterWeb not crash with the same code while this does? The only answer I have is different compilers... I am working on putting better checks in. The TenFourFox code is only using one set of limits while there are two... So I am going to check against both limits. |
|
@dbsoft Awesome, thank you for working on this! |
|
@dbsoft how is this going? I'm interested in banging my head against it a bit, and will probably try building it tomorrow. Anything I should know? My boss used to contribute to Mozilla, and knows a ton about the particular problems and solutions of the Solaris SPARC version of Firefox, so I'll definitely consult him as well if I run into anything I think he'd have insight on. |
|
I think I have the font crashes fixed in my local tree but then I hit a crash in the CoreGraphics backend I just restored. I have been spending the week working on getting my relative's estate in order.. and haven't had time to look into the new crash I ran into... won't be able to look into it further until this weekend. |
|
@dbsoft Brian, any update on this? I am away from my PowerMacs until middle of next week, but once back I am very much interested to follow up with fixing this. |
|
@barracuda156 The estate issues basically have been consuming my time, but I am getting back into things this week. Sorry for the delay. |
|
Sounds good. I am sorting out the build of gcc13 on Leopard now – right now trying to get For https://github.com/barracuda156/macports-ports/tree/gcc_move
It is usable now via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@dbsoft Hi, Brian!
@wicknix referred me to your discussion on PaleMoon board, and I am interested to join into the project :)
What is the current status of the build?
P. S. There is also a relevant discussion here, which may be worth taking a look: rmottola/Arctic-Fox#140
The text was updated successfully, but these errors were encountered: