gcc/config/darwin.h differences between 10.5 & 10.6 #32
Replies: 19 comments 60 replies
-
|
@kencu This may be a question for you, since it is related to Even stranger, I have built now Nothing else changed aside of disabling Help me please, I cannot go on with trial-and-error approach here, it is multi-hour endeavor every time, and I already did two builds resulting in broken |
Beta Was this translation helpful? Give feedback.
-
@iains I will rebuild it and update you. I beg a pardon here, I did not expect this problem to occur on 10.6.8, so went with |
Beta Was this translation helpful? Give feedback.
-
|
If the build completed without error, then I would expect the library to be present - but, yes, better to check (CPU cycles are less hard to find than engineer cycles). did you try |
Beta Was this translation helpful? Give feedback.
-
Well, I guess I found an answer: Portfile has no mention of this dylib: https://github.com/macports/macports-ports/blob/master/lang/gcc11/Portfile |
Beta Was this translation helpful? Give feedback.
-
Yes, I understand, and I greatly appreciate that you respond to me.
I only have |
Beta Was this translation helpful? Give feedback.
-
|
@kencu et. al. So the port file will need amendment for 11.3+ (including the up-coming gcc-12) to include the _ehs file for all darwin <= 10.6. Also, for anyone who will be working with the arm64 port, that does NOT include libgcc_s.1.dylib, since this is a new port, there is no need for a "backwards compatibility" mode. |
Beta Was this translation helpful? Give feedback.
-
|
please note that I will be producing a Darwin branch in the next few days that includes the Arm64 support and some patches that I did not have time to include in 10.3.0 (but that does not affect this current issue AFAICS). |
Beta Was this translation helpful? Give feedback.
-
|
@iains I attach the log (some part in stage 1 missing due to reboot) and actual resulting archives from Macports software folder, as well as Portfile and patches used. All these from 10.6.8 Server (not from 10A190). |
Beta Was this translation helpful? Give feedback.
-
|
NOTE: comparing with 11.2 is not useful here, since 11.2 does not have the fix for PR80556 (which changes the library layout). |
Beta Was this translation helpful? Give feedback.
-
@iains Sorry, I did not mean I want you to read everything through or check archives, this is just in case for reference. I just want to understand why building @11.3.0 fails even on 10.6.8 (and hopefully get a hint how to fix it myself for 10A190, since just changing conditions to have 10.5 policies applied now fails). |
Beta Was this translation helpful? Give feedback.
-
Got it. So this list is deficient, right? This is what I got with And then Macports complains re missing |
Beta Was this translation helpful? Give feedback.
-
|
11.3.0 builds fine (and tests 'nominally') on x86_64-apple-darwin10 (https://gcc.gnu.org/pipermail/gcc-testresults/2022-April/759645.html). So I am asking you to check the build to see if there's something missing on powerpc - just in case. |
Beta Was this translation helpful? Give feedback.
-
I will rebuild now in Rosetta and tomorrow on 10.6 PPC, and update here. |
Beta Was this translation helpful? Give feedback.
-
|
there are some apparent changes in the libgcc11 libraries that MacPorts has not yet accounted for, so you'll just have to wait a bit until that is fixed in MacPorts. Presumably some of these libraries that no longer exist in gcc 11.3.0 will now be provided in macports by libgcc 10. |
Beta Was this translation helpful? Give feedback.
-
|
There are no libraries removed by 11.3 (and 12) for powerpc, i686 or x86_64 I'd guess a relatively simple fix (but not familiar with the system so ICBW). |
Beta Was this translation helpful? Give feedback.
-
|
it would be great if we could find some way that you folks could test the branches before they release .. (I realise that you want to focus on released versions - but the only way to make sure that those released versions are easy to use and not broken is to test them before they are fixed in stone). |
Beta Was this translation helpful? Give feedback.
-
|
BTW, although I have not done it yet (so I might still run out of time) - the fix for PR80556 should be applied at the least to 10.4 (we must try to ensure that 10.4 is a solid bootstrap compiler for the system versions that only have a c++89 native compiler). |
Beta Was this translation helpful? Give feedback.
-
we do actually do that. We have gcc-devel that tracks the latest commits, and would have seen this. However, MacPorts has many different contributors, and sometimes people see a shiny new penny and just update to it, then let the dust settle after. One of the reasons that I usually hang back my important systems on MacPorts by a few months. |
Beta Was this translation helpful? Give feedback.
-
Is there one of these for 10.x? 10.4 is going to be very important for us, since if we mess up there, we have to wait ≈ 1 year for the final ... (much like we now have to wait ≈ 1 year for 11.4 to fix any fallout we find from 11.3) .. (or local patches of course). (now would be a good time to crank up testing for master - since we are a few weeks away from GCC12 branching, I would think)
Yeah, it's all voluntary, I realise .. just trying to find a strategy that makes best use of the voluntary time ;)
heh, me too ... I do not use latest & greatest for any production system, I have to say .. regardless of the source of the s/w (unless, of course, that's the only tool that supports a required feature, I suppose). |
Beta Was this translation helpful? Give feedback.
-
@iains I am finally back to my PPC hardware and trying to minimize changes needed for GCC12 to build on 10.6 PPC. Looking into There are just three instances related to unwinding, from what I can see, and those are not present in rs6000 header but only in the main Darwin one.
Of course I can try patching these one at a time to see what eventually works, but if you can give an advice, that would be very helpful. As always in such cases, I am only asking for your opinion, not wasting your time to try anything in practice (that I do on my end anyway). P. S. It may be perhaps possible to fix 10.6 PPC instead (so that GCC builds on it like on Rosetta), but I don’t know which OS lib has to be backported. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I believe that I tried the 12.2 branch on both 10.6.8 and 10.5.8 Rosetta and it worked on both .. so it might be that you are seeing some fallout from the "not quite a release" scenario with mixed DP and distribution. |
Beta Was this translation helpful? Give feedback.
-
|
@iains Thank you, this is very helpful. The initial failure (no patches) was with dynamic linking: After I added this patch: Then the build proceeded, but failed on static linking here: Is |
Beta Was this translation helpful? Give feedback.
-
|
I think your fix is probably wrong. If I do this on a stock 10.6.8 system: So the symbols are present in libSystem (which is what we expect on 10.6+). Now, you quoted the libtool link line - which does not actually show the final link line. That should have "-lSystem" which should therefore, pull in the symbols that are complained about I suggest next: |
Beta Was this translation helpful? Give feedback.
-
|
since I'm checking 12.2-darwin-r1 .. |
Beta Was this translation helpful? Give feedback.
-
|
@iains Here is what I get (removing 10.3–10.5 versions): Then, for And for So it seems symbols are there, but for some reason they do not get picked from libSystem. |
Beta Was this translation helpful? Give feedback.
-
So.. I think you will need to a -lgcc_s.10.5 to your link line or something similar .. it's hard to know What does I fear that you are entering the "on your own" part of the forest .. since it's not at all clear to me that you can make a consistent set of unwinder uses if part of the system expects the symbols in libSystem (the genuine 10.6 part) and part is expecting something a bit like 10.5 (the DP part). |
Beta Was this translation helpful? Give feedback.
-
|
Here is the log prior to undefined symbols error quoted above (the first one, no patches added from my side): I can find |
Beta Was this translation helpful? Give feedback.
-
|
-lSystem is added by the compiler (you are still looking at the libtool link lines, not the actual linker input). anyway, we know what the problem is - adding -lSystem will make no difference since the symbols there are marked as invisible. I have no idea if adding -lgcc_s.10.5 will work (that's why I asked about what /usr/lib/libgcc* is) |
Beta Was this translation helpful? Give feedback.
-
I believe that what would my patch above do, emulating behavior on 10.5.x? Like it is done for some other settings for Rosetta in rs6000 Darwin header.
Yeah, I understand that, but even with earlier (obviously far from optimal) patches What I look for now is: |
Beta Was this translation helpful? Give feedback.
-
|
and |
Beta Was this translation helpful? Give feedback.
-
|
which versions of gcc10 and gcc11? If you were using a version before libgcc_s was fixed, then it might look like it worked - but was still actually wrong. |
Beta Was this translation helpful? Give feedback.
-
|
@iains Output: GCC versions: gcc10 10.3.0, gcc11 11.3.0 (I did not run tests, but gcc10 is able to build gcc11, gcc11 builds Cmake, icu and tons of ports. I cannot yet confirm gcc12 on 10.6 PPC, as that is in the process. |
Beta Was this translation helpful? Give feedback.
-
|
OK. So it looks like linking with libgcc_s.10.5 should work. Two points about the patch above - why 10.6.1? and not 10.7 (not 100% sure it will do what you expect with 10.6.1). We take care to 0 the micro versions so that any version of 10.6.x would be supported (there are also other reasons, to do with newer linkers expecting this too). from So you also need to amend the static link case. GCC-10.3 did not have the fixes, I think, but 11.3 did .. |
Beta Was this translation helpful? Give feedback.
-
|
and I remain concerned that you might well be running into the situation where some system libraries have their unwinder in libSystem (the one from 10.6) and some have their unwinder in libgcc_s.1.dylib (the ones from DP). That kind of problem is exactly the one we have just fixed with the re-work of libgcc_s. essentially, you can only have one unwinder in a process - because it has global state. |
Beta Was this translation helpful? Give feedback.
-
Given that this is unlikely to be incorporated in either GCC itself (unless there is a way to specify pre-release builds – there is none, right?) or Macports (we got opposition, so to say), this is a purely aesthetic matter.
Already done after I got a second failure upon fixing (for w/e it’s worth) the first one. What I am not sure is whether emutls should be changed likewise or left as is.
Is there some test case to evaluate the issue on 10A190? So as to find out if GCC works correctly or not in this specific regard. |
Beta Was this translation helpful? Give feedback.
-
I do not think that there's any reliable way of detecting that this is DP (possibly mixed with some libraries from other places) .. plus 10.6.0 was also a real release. The best assumption to make is that this would remain a private branch for people who want to experiment with the 10A190 DP .. I would not expect any upstream (GCC or macports) to want something like that because it's incredibly hard to maintain (PPC Darwin is pretty hard already because not much hardware and it's slow).
If (you have the shared libgcc_s.1.1.dylib) then There is no emutls support in /usr/lib/libgcc_s.1.dylib (but that does contain the unwinder).
It is not GCC that needs to be tested - the problem occurs when an exception is thrown in an application built with GCC iff that application uses two unwinders (tends to result in a hang or an unexpected termination) |
Beta Was this translation helpful? Give feedback.
-
|
@iains Good news: gcc12 has built through completion with this patch (so all changes moved to PPC header): Bad news: another fix needed (and rebuild libgcc12 and gcc12 once again) in regard of Another error when building Perhaps this should fix it? (I want to make clear that both Python and jemalloc built fine with gcc11 on 10.6 PPC, so these errors are caused by me not patching some setting correctly, not by GCC or 10.6 PPC as such – since I am trying to minimize required changes.) And to clarify whether I need
There is no such system dylib in 10A190 (but also in 10.5.8, from what I see). This dylib is installed with gcc12 itself though. P. S. I noticed that gcc12 build used |
Beta Was this translation helpful? Give feedback.
-
There are pre-installed (clonable) clean images of 10A96 and 10A190. I use those, as that is quicker than manual process. Manual process works, but there are some non-trivial issues from what I remember. Let me find 10A96, it was buried in comments there, but I never used 10A96 on its own – only borrowed components for WiFi on a PowerBook. Macports does not build on 10A96 (with or without Ken’s hack to sandbox). |
Beta Was this translation helpful? Give feedback.
-
|
@iains As a quick note: what some folks write in Macrumors thread re only Xcode from 10A96 being usable is nonsense. I pointed that out several times, but this myth is still around. Xcode from 10A190 is to be used on 10A190. In fact, even Xcode tools from 10A222 are functional (but require replacement of 3–4 binaries) – I used those for a while, but eventually reverted to 10A190 Xcode. |
Beta Was this translation helpful? Give feedback.
-
|
@iains So to sum up, what exactly I did (I have 10A190 installed on two PowerMacs G5 and a PowerBook): Download dmg of 10A190 (pre-installed), clone via Disk Utility, boot into it, then install Xcode from 10A190 DVD iso. Few notes on software: Potentially later Xcode tools may work if rebuilt with ppc slices (some binaries lack those in released Xcode 3.2.x – dropping of ppc in Tools began already with Xcode 10A222, though most apparently retained ppc slices all through Xcode 3.2.6). |
Beta Was this translation helpful? Give feedback.
-
|
yeah, I don't think so .. the G5 is too busy with regular work ;) |
Beta Was this translation helpful? Give feedback.
-
@iains I realize you are busy and scarce resources may have better uses :) But whenever you feel curious to give it a try, please tell me, I can provide all info and make clonable dmg with Xcode tools installed – installation itself is a matter of few minutes then. P. S. I will see if I can arrange a remote access to my PowerMacs. (I am eager to, just need to find out technicalities.) |
Beta Was this translation helpful? Give feedback.
-
@iains I lack the expertise required to judge which is preferable. Yes, some components are newer in 10.5.8, though not all (there is a table with some comparisons in Macrumors thread), and I have no idea which will be comparatively easier pathway. Of course, including PPC64 would make it much better. It could be a decisive factor, IMO. Have you tried restoring PPC64 in 10.6.8 Rosetta? You mentioned that idea somewhere earlier.
Once I am back to uni office, I will try – G5 Quad with external drives for testing is there. P. S. As a matter of curiosity, 10A190 installs in Parallels from DVD iso, but trickery needed, since it is not a server version. But technically one can run it on Intel. Rosetta is not there yet, but ppc binaries build and run. |
Beta Was this translation helpful? Give feedback.
-
The process I was intending to describe was the one above - where essentially we would take a 10.5.8 system and make the best update possible (given the available sources). Adding ppc64 back to Rosetta would not be possible, there are too many missing sources. [and Rosetta 1 itself only emulates a ppc7400] |
Beta Was this translation helpful? Give feedback.
-
@iains Just to be clear here: do you consider this approach preferable because of ppc64, because of higher success probability or something else? |
Beta Was this translation helpful? Give feedback.
-
Both - the upgrading of components with available sources is well-controlled. The possible upgrading of the kernel could also (with enough available free time) be controlled; I'd assume that we would want a few key features (e.g. libdispatch and blocks, modern certs) - not so much all the fluff that's been added to the system.
It does not seem more natural to me - since (it seems even to get a bootstrap) you are mixing components from different builds without visibility of whether interfaces are being broken (except if something crashes). |
Beta Was this translation helpful? Give feedback.
-
|
Just an update: Python error is gone (once I do not build
|
Beta Was this translation helpful? Give feedback.
-
|
OK, for the record (I don't intend to spend any more time on this). Neither the pre-built nor a manually-built 10A190:
This highlights the problem - the whole thing is incredibly fragile, depending on a mix of kexts from old and new systems, any slight deviation from a tested set is likely to need changes to the kexts loaded. The problem on the G5 is likely associated with AHCI which, unfortunately is one of the drivers we do not have sources for - I think the PureDarwin project was planning/intending to write a replacement from scratch, but not looked recently. So, IMO, this approach is probably a non-starter for very many people, perhaps it will work for a narrow range of hardware, but then you plug something else in and boom kernel panic. out of curiosity, on the G5 you have working what is the output of |
Beta Was this translation helpful? Give feedback.
-
|
@iains Also just for the record. I got a Sonnet Tempo SSD PCIe card now – to be able to use newer and faster SSDs, and lo and behold, neither 10A190 nor 10A96 can boot with the card installed, failing into KP on the boot. Safe boot did not help, so apparently the issue is not solved by swapping kexts (?). Boot into OperFirmware, then: (Device depends on the PCIe slot used, I believe.) |
Beta Was this translation helpful? Give feedback.
-
|
@iains Thank you for the update. Sad that it does not work. Drivers might be an issue on G5, indeed. Both my PowerMacs G5 are pretty standard in a sense of components - Quad has one of HDDs replaced with SSD, that is it. ATI 1900XT (original for Apple) has no hardware acceleration (or something related), but works normally. Nvidia card is fully supported. Case of PowerBook is a bit surprising. I know for sure that 10A190 works on PB G4 1.5 GHz 2005 and on MacMini G4, cannot remember the model, perhaps 1.4 GHz, one of the latest. But who knows, maybe some unsupported video card or smth else. This is from G5 2.3 GHz (I think 10A190 here has not been tweaked): I will update with the output from Quad tomorrow, hopefully. It is sitting in uni office. |
Beta Was this translation helpful? Give feedback.
-
|
We have one (1) Iain. He is the only compiler engineer working with gcc for MacOS. Having him spend 99% of his time in these forums debugging 10.6 on PowerPC issues is counterproductive to all the real work that needs to be done. But he has already said he will spend no more time on it, so hopefully that will be the end of the questions about it. |
Beta Was this translation helpful? Give feedback.
-
|
@kencu Most of the topics here are unrelated to 10.6 PPC – not any more as being related to PPC as such. I did not and do not ask anyone to debug or fix anything for 10.6 PPC. My personal preferences with regard to what I do in my spare time, I hope, won’t be a disturbing factor :) |
Beta Was this translation helpful? Give feedback.
-
|
(I have no axe to grind on doing ridiculous projects for hobbies - after all, I'm half way there supporting all these Darwin versions on GCC :-D ) From my point of view, I wanted to see if there was any merit in pursuing this (10.6 DPs) - as I have said before, I personally favour making a "10.5.9" release with updates to all of the components we have sources for. Nevertheless there is an attraction to Darwin10 (or better 11) in that some critical features were added especially blocks and some parts of Posix. My technical conclusion is that 10.6DP is unworkable - because I do not believe we can find any agreed configuration that would be generally useful - it's a waste of time trying to explain kext dependencies to most end users. So, one day when I have more time on my hands I might pursue "10.5.9" but (as things stand) I will not be putting any more effort into 10.6DP. |
Beta Was this translation helpful? Give feedback.
-
|
my apologies for seeming too dogmatic. I do have an opinion on this, hopefully spoken clearly but not excessively, but hobbies are fun, and pursue what you wish. @barracuda156, you are learning a lot about macOS, gcc, and macports, and whatever led you to this is certainly fine. |
Beta Was this translation helpful? Give feedback.
-
|
macports offers blocks as an available port for < 10.6 https://ports.macports.org/port/libblocksruntime/ it does a fine job to supply that functionality to such systems. I had hoped that libdispatch might similarly be added. Most of the posix bits that are found on 10.7+ have been added to older systems by legacysupport: |
Beta Was this translation helpful? Give feedback.
-
|
probably. just look up what it is supposed to be in some newer SDK, and add that line to the legacysupport overlay in the right header. but there is one extra bit to ponder -- and that is, what did it do? If it does something that changes how code works, it could be an issue to define it. For example, gcc looks to see if AI_NUMERICSERV is defined, and if it is, it calls code blocks that actually use AI_NUMERICSERV's functionality. Up to now, on systems where AI_NUMERICSERV was undefined, all has worked well. But if it is now magically defined on a system that doesn't support what it can do, then Bad Things Might Happen. So you need to think a bit about what defining something like AI_NUMERICSERV might actually mean to a build. It may be better to leave it, and add blockers like gcc did for it. |
Beta Was this translation helpful? Give feedback.
-
|
or you may need to enhance the function to duplicate what the added define might expect, like I did for sysconf on Darwin, to support a few newer defines and capabilities that were becoming commonly used, for example here: |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, if it's not defined then define it to 0 is usually safest. Sometimes we can (as @kencu says) add some shim function to augment what's already there - sometimes we cannot because there is some kernel (or libc) support that is needed. |
Beta Was this translation helpful? Give feedback.
-
I thought that lib dispatch was one of the cases that needed kernel support added at 10.6 (but maybe I mis-remember). |
Beta Was this translation helpful? Give feedback.
-
|
BTW, for the specific case of AI_NUMERICSERV - I did figure out what to do because that is used by the c++tools subdirectory in GCC (which is likely what @kencu is referring to above) - so I could be reasonably confident that the strategy there could be re-used if you encounter cases elsewhere. Of course, with the restriction that you cannot use that mode. |
Beta Was this translation helpful? Give feedback.
-
|
@iains I tried building And another missing symbol (happens only on 10.5.8) is another instance of |
Beta Was this translation helpful? Give feedback.
-
|
so for this specific case, we sorted out jemalloc is using the gcc compiler to link g++ code, and that caused the failure. Not a gcc issue. |
Beta Was this translation helpful? Give feedback.
-
@iains This is not an urgent matter, but I will greatly appreciate your comment, when you have few extra minutes.
gcc/config/darwin.hhas several settings that differentiate between 10.5 & 10.6 (this is nothing new, though the recent updates togcc10andgcc11modified some of those).Besides an obvious fact that several of these refer to specific libs/objects which may or may not be present in the host OS, what in particular do they control? Is resulting configuration on standard 10.6 better than on 10.5 in practical terms? I mean, is there an advantage to gain, or it is just a matter of compatibility with little to no consequence for compiler’s functionality?
There is a practical bearing to this matter: while original @kencu solution for building
gcc7on 10.6 PPC was to “trick” config into thinking it is more or less 10.5, it may not be necessary to change all of these settings. For example,crt1.10.6.oexists in 10A222 (the build which is very close to 10A190 with many compatible components), and I have just builtgcc11on 10A190 leaving>< 10.6 10.8 mmacosx-version-min= -lcrt1.10.6.oas is, and it worked. But I don’t know if it makes sense to do such peace-meal adjustments.P. S. While I ask this in relation to
gccon 10A190, I don’t expect an answer based on the knowledge of 10A190 as such. I just need to understand what differs between 10.5 & 10.6, and then I can figure out where exactly “in between” lies 10A190, and in which ways it can be brought closer to standard 10.6 (10A432).@kencu @catap Tagging you in a case you may be interested to join.
Beta Was this translation helpful? Give feedback.
All reactions