Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, I actually agreed with you, just skip from gcc7 to gcc13. Ken Cunningham wrote: Just yesterday I fixed gcc10-bootstrap to build on Tiger PPC and pushed that to master, which required YA new bootstrap compiler. So the parts are now in place for the attempt. ohhh :) it took me 4 days to get libgcc7 and gcc7 on Tiger from scratch ... wanted to report that separately... older systems are slow :) If everyone wants all the gcc versions supported, we can do that. I don't care -- it's just a lot of building (and also fixing that will need to be done, but I presume you'll pitch in on the fixing of the broken gcc versions). well... if you have gcc10 fixed, can we do gcc7-gcc10+gcc13 ? I suppose that if we need an in-between compiler it can be added later? What about adding more stubs? Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
> On Apr 7, 2024, at 11:24 PM, Riccardo Mottola > wrote: > > Hi, > > Ken Cunningham wrote: >> Up to now, though, older systems have used gcc7, and in a few cases gcc5 or >> gcc48 are used for specific issues. So those gcc versions may still be >> needed ... time will tell. > > for me it is gcc48 (or apple 4.2 on tiger or such) for old software. gcc6 > covers most needs and gcc7 is "current". Who knows, maybe gcc13 replaces gcc7 > in all its uses. Or maybe later we can add gcc8 or whatever. > > Let's switch? I hope gcc's can be added later, maybe even with libgcc stupped? > > If we do it today or tomorrow, I can leave my G4 building :-P > > Riccardo Just yesterday I fixed gcc10-bootstrap to build on Tiger PPC and pushed that to master, which required YA new bootstrap compiler. So the parts are now in place for the attempt. If everyone wants all the gcc versions supported, we can do that. I don't care -- it's just a lot of building (and also fixing that will need to be done, but I presume you'll pitch in on the fixing of the broken gcc versions). K
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, Ken Cunningham wrote: Up to now, though, older systems have used gcc7, and in a few cases gcc5 or gcc48 are used for specific issues. So those gcc versions may still be needed ... time will tell. for me it is gcc48 (or apple 4.2 on tiger or such) for old software. gcc6 covers most needs and gcc7 is "current". Who knows, maybe gcc13 replaces gcc7 in all its uses. Or maybe later we can add gcc8 or whatever. Let's switch? I hope gcc's can be added later, maybe even with libgcc stupped? If we do it today or tomorrow, I can leave my G4 building :-P Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Once gcc13 is the default gcc used on older systems, it would be hoped that it would cover off most needs. Up to now, though, older systems have used gcc7, and in a few cases gcc5 or gcc48 are used for specific issues. So those gcc versions may still be needed ... time will tell. If the whole gory mess of gccs are left enabled, then to get gcc48, gcc5, or gcc7, you will need to build a large bunch of needless libgccs to get them. With no buildbot, that would pretty much suck. The "better solution" is pretty clearly don't enable the needless gccs on ancient systems -- problem solved.
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Two of the libgccs are stubs, the rest are not. so it is pretty much as bad as it looks.
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
On Apr 5, 2024, at 13:03, Riccardo Mottola wrote: > > Odd/Even was an old practice, possibly not followed anymore. It was an old practice of GNOME abandoned in 2020. Graphviz, Cairo, Pango, Pixman, Glib2 are examples, from ports I maintain(ed). The MacPorts "gnome" livecheck recipe still follows this rule. Never heard of gcc following it. All I remember about gcc's versioning is that prior to version 5, the branch name consisted of the first two numbers in the version number, and as of 5 it is only the first number. Thus the branches are e.g. 4.7, 4.8, 4.9, 5, 6, 7, etc.
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
> On 5 Apr 2024, at 7:03 PM, Riccardo Mottola via macports-dev > wrote: > > Hi, > > Ryan Schmidt wrote: >>> I propose to keep even versions, because they are stable ones >> Do you have a source for this claim? It's the first I've heard of it. As far >> as I know, all gcc version numbers are stable. >> > > I did a quick search and couldn't find one. It is something I pked up years > ago and is a bit corroborated by experience on compiling on dozens of systems. > but no trace on the gcc time. > Odd/Even was an old practice, possibly not followed anymore. I don’t believe it was ever an official policy followed by gcc… > > Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, Ryan Schmidt wrote: I propose to keep even versions, because they are stable ones Do you have a source for this claim? It's the first I've heard of it. As far as I know, all gcc version numbers are stable. I did a quick search and couldn't find one. It is something I pked up years ago and is a bit corroborated by experience on compiling on dozens of systems. but no trace on the gcc time. Odd/Even was an old practice, possibly not followed anymore. Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
On 05/04/2024 1:45 pm, Ryan Schmidt wrote: On Apr 5, 2024, at 03:52, Riccardo Mottola wrote: I propose to keep even versions, because they are stable ones Do you have a source for this claim? It's the first I've heard of it. As far as I know, all gcc version numbers are stable. They are. There is no 'even is stable' convention with GCC. Chris
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
On Apr 5, 2024, at 03:52, Riccardo Mottola wrote: > > I propose to keep even versions, because they are stable ones Do you have a source for this claim? It's the first I've heard of it. As far as I know, all gcc version numbers are stable.
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, On 05/04/2024 12:30 pm, Ken Cunningham wrote: It’s important you understand how the libgcc ports work now, to see how this libgcc chain is set up and the problems it might cause on slower older systems that have no buildbot. Go to an Intel system like 10.7, uninstall all ports. Disable the buildbot by clearing archive_sites in sources.conf. Then try to install gcc7. gcc7 of course requires libgcc7. But because libgcc7 depends on libgcc8, libgcc8 will have to be built first. But because libgcc8 depends on libgcc9, libgcc9 will have to be built first. But because libgcc9 depends on libgcc10, libgcc10 will have to be built first. But because libgcc10 depends on libgcc11, libgcc11 will have to be built first. But because libgcc11 depends on libgcc12, libgcc12 will have to be built first. But because libgcc12 depends on libgcc13,:libgcc13 will have to be built first. And libgcc13 is the end of the chain currently…until libgcc14 comes along. Just to add though, quite a number of those libgccN ports are simply stub ports, that do not actually build anything but exist simply to define the dependency chain. e.g. libgcc12 is just Larissa ~/Projects/MacPorts/ports > port contents libgcc12 Port libgcc12 contains: /opt/local/share/doc/libgcc12/README So the *build* chain is no where near as bad as the above might suggest, as these stub ports take no time to build or install. ... and, if you are wondering why we have this setup, the basic idea is the latest gcc version, for a given OS, provides the default libgcc runtime. e.g. libgcc at the moment just depends on libgcc13. Then, older libgccN versions simple add to the runtime additional *older* versions of various libs that that particular gccN needs, and which the newer gccN+ do not provide. The reason for doing this is :- a) the newest gcc vesion always provides the version of a particular runtime library b) all gcc versions that use that runtime share the exact same binary. This systems works well, and whilst anyone can if they wish propose a new one, they will have to demonstrate the reasons why it is better. It is assumed that *most* users only need a single gcc version, and the latest is almost always all they need. So most users only need libgcc13 and gcc13 (at this time). cheers Chris So that is the chain. It is pretty easy to have libgcc7 depend on libgcc13 instead of libgcc8 on older systems, and skip a bunch of this chain. And in base, it’s pretty easy to make gcc7 and gcc13 available compilers on these systems, and not the in between gcc versions. It would be messy in both libgccN dependencies and base to skip odd versions of gcc and support even versions. Doable, but messy and confusing for coding and blacklisting. And little point to it. And finally, if we are going to update libgcc, we might as well use the current libgcc, rather than the obsolete libgcc8. [Barracuda has been suggesting to start up a completely new, separate gcc-ppc port at gcc13 that he would control…but I see no point to that, as it would just be our current gcc13 port anyway with a couple more patches, would break the ”one libstdc++ rule” for all the other gccs in so doing, and make a shambles of gcc compiler selection in base and blacklisting in portfiles.]
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
It’s important you understand how the libgcc ports work now, to see how this libgcc chain is set up and the problems it might cause on slower older systems that have no buildbot. Go to an Intel system like 10.7, uninstall all ports. Disable the buildbot by clearing archive_sites in sources.conf. Then try to install gcc7. gcc7 of course requires libgcc7. But because libgcc7 depends on libgcc8, libgcc8 will have to be built first. But because libgcc8 depends on libgcc9, libgcc9 will have to be built first. But because libgcc9 depends on libgcc10, libgcc10 will have to be built first. But because libgcc10 depends on libgcc11, libgcc11 will have to be built first. But because libgcc11 depends on libgcc12, libgcc12 will have to be built first. But because libgcc12 depends on libgcc13,:libgcc13 will have to be built first. And libgcc13 is the end of the chain currently…until libgcc14 comes along. So that is the chain. It is pretty easy to have libgcc7 depend on libgcc13 instead of libgcc8 on older systems, and skip a bunch of this chain. And in base, it’s pretty easy to make gcc7 and gcc13 available compilers on these systems, and not the in between gcc versions. It would be messy in both libgccN dependencies and base to skip odd versions of gcc and support even versions. Doable, but messy and confusing for coding and blacklisting. And little point to it. And finally, if we are going to update libgcc, we might as well use the current libgcc, rather than the obsolete libgcc8. [Barracuda has been suggesting to start up a completely new, separate gcc-ppc port at gcc13 that he would control…but I see no point to that, as it would just be our current gcc13 port anyway with a couple more patches, would break the ”one libstdc++ rule” for all the other gccs in so doing, and make a shambles of gcc compiler selection in base and blacklisting in portfiles.]
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, Ken Cunningham wrote: To have libgcc7, the way it is now, you need to build libgcc13, 12, 11, 10, 9, 8, and then 7. That is -- a lot of gcc building for a questionable benefit. on my PowerMac dual-G4 about a week of compilation, given the time to build gcc8... But I understand we always build "latest available" (currently gcc13).. but I don't understand the chain. We need a newer library. I agree with you that having all in-between version is nice but too much of a compile burden! I have following ideas: 1) not jump to gcc13, but "just" to gcc8, gcc10 or whatever. Bandaid.. until we decide to raise the bar more! 2) do what you propose is gcc7 - gcc13 3) a "good sense" of some between versions. I propose even versions or a subselection of them. I propose 3) but an fine with 2... let's just update! Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi,
Ken Cunningham wrote:
My only question is whether to skip over gcc8-12, or include them.
If we skip over gcc8-12, we can probably have a new release that uses
gcc13 as the primary gcc on all systems in macports done by Monday.
Less maybe. Last time I jumped the version, it took me an hour.
Is gcc13 tested enough? I fear that since we are left at gcc7 for a long
time, that's the tested one.
And then — no more worries. Existing macports base infrastructure will
just work as it is. Some fairly minor tweaking of what compilers are
available on which systems will be done.
If we have to fix all the gcc versions between gcc8 and 12 — well that
will take a bit more time to fix and to build.
6-7-13?
6-7-8-10-12-13?
6-8-13?
giving numbers :) Keep odd compilers only if it is the last current
available.
What's actually to "fix" later and add in-between gcc's if needed?
For Riccardo’s bug, we always knew the gcc JIT was fragile on 32 bit
systems. It probably needs to be disabled there by tweaking this block
in the gcc8
so you think the issue is 32bit ppc and I would have issues on 32bit
intel too? I need to fix that fan and test :)
Portfile:
if {${subport} eq "gcc8"} {
# the jit is not building on i386 systems
# seehttps://trac.macports.org/ticket/61130
if {${build_arch} ne "i386"} {
lappend gcc_configure_langs jit
}
}
Maybe that’s all it needs.
add ppc 32bit only?
Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, Sorry - I missed these replies, ended up in the wrong mail folder. Was about to re-write! We had discussions in many points, tickets, ecc... lots of different opinions. Sergio Had wrote: You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I have seen people using gcc13 on 10.5 ppc following my instructions from the PR. What is the point of gcc8? Some people think it is good to have all versions. Other voice for directly gcc13. Would we keep gcc6 in this jump? what we do with the working gcc7 we have? I propose to keep even versions, because they are stable ones and often found long-term in Linux and BSD distributions. If you think, we still tinker with gcc4.8, gcc6... but I never felt the need for gcc5 (although one never knows for stubborn pieces of software) I just started with gcc8 because it contains already some libc++ features I was needing without jumping to gcc13 and because it was the next logical attmept. It was just a test to see how things are set on intel and PPC. I make the question the other way around. We have this "gap" because these older platforms were not updated in their gcc versions regularly. Otherwise, I suppose, we would have all versions up to gcc13. When gcc14 comes out, what will happen? Keep gcc13 and use libgcc14? Other question: why do we have to "chain" all gccs so that having them all means building them all? I supposed I just need the ealierst ancestor which is capable of correctly compiling that said version of gcc. So If gcc8 (supposed, not tested) is enough to compile libgcc13.. why can't I just have gcc8 and gcc13... and later if I want install gcc10 or if I don't want, not? Just ideas (and dumb questions). Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
In general, the more a given system deviates from the main herd of ports, the
more likely there are to be problems and the less likely they are to be fixed.
To be honest, I don’t see why a new gcc port to be used only for powerpc is
needed.
My only question is whether to skip over gcc8-12, or include them.
If we skip over gcc8-12, we can probably have a new release that uses gcc13 as
the primary gcc on all systems in macports done by Monday. Less maybe. Last
time I jumped the version, it took me an hour.
And then — no more worries. Existing macports base infrastructure will just
work as it is. Some fairly minor tweaking of what compilers are available on
which systems will be done.
If we have to fix all the gcc versions between gcc8 and 12 — well that will
take a bit more time to fix and to build.
For Riccardo’s bug, we always knew the gcc JIT was fragile on 32 bit systems.
It probably needs to be disabled there by tweaking this block in the gcc8
Portfile:
if {${subport} eq "gcc8"} {
# the jit is not building on i386 systems
# see https://trac.macports.org/ticket/61130
if {${build_arch} ne "i386"} {
lappend gcc_configure_langs jit
}
}
Maybe that’s all it needs.
Ken
> On Mar 29, 2024, at 4:50 AM, Sergio Had wrote:
>
> Well, the PR is either merged or not merged :)
>
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Well, the PR is either merged or not merged :) I think my proposal addresses all possible rational concerns. If irrational concerns will happen to dominate, well, I can’t do anything about that. > On Mar 29, 2024, at 7:47 PM, Ken Cunningham > wrote: > > I am not a MacPorts admin, however I believe they were pretty clear that > 10.6-ppc-specific fixes belong in an overlay repo, not in macports code. > > If you want that changed, take it up with them. > > I personally agree with that decision, so I abide by it, until such time as > it changes. > > K > > > >> On Mar 29, 2024, at 04:00, Sergio Had wrote: >> >> >> Ken, the last time you objected to having gcc10-bootstrap building for ppc >> on 10.6 in gcc13 port. >> Because that was extra 10 characters of code in the macro, which was too >> ugly to tolerate, apparently. >> (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use >> clangs on any powerpc, be it released macOS or pre-released.) >> >> Anyway, what I suggest is the following: >> >> 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be >> only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti >> code”, which you dislike. >> 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can >> add tweaks I want, and restrict that port to PowerPC. Throw away everything >> unneeded from there, make it easy to maintain. >> >> To that separate port I can add support for libc++ on PowerPC, fix IEEE >> arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which >> will not land into any other gcc ports, unless someone else – not me – >> decides to pick that. >> >> As I bonus I (and whomever decides to use it) can avoid unnecessary >> revbumps, wasting many hours of compilation time for nothing, and on the >> other hand revbump powerpc port without causing pain to anyone else. >> >> I honestly hope this can keep everyone satisfied. >> >> I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, >> since we should not have a disagreement anymore. >> >> >>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham >>> wrote: >>> >>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had >>> anything to do with why nobody had gotten around to updating the gcc >>> version used on older systems. >>> >>> At least, it was not anywhere on my radar. >>> >>> Just -- nobody did the legwork. >>> >>> Ken >>> >>> >>> On 2024-03-28, at 11:47 AM, Sergio Had wrote: >>> Let me make another, final attempt to sort this out once for all and for everyone on old systems. I got an idea how to satisfy Ken’s preference of not supporting ppc builds on 10.6 in gcc ports and my need to support those. That was the stopper so far, not allowing an agreement to merge. I may do this today itself: I have everything working for months, just need to sort commits to make it readable and implement a solution for what I want. As a bonus, you will get IEEE intrinsics in Fortran – something that never existed on ppc. On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote: > You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 > too). I have seen people using gcc13 on 10.5 ppc following my > instructions from the PR. > > What is the point of gcc8? > > You build gcc10-bootstrap and then use it to build gcc13. Nothing else > needed in between. > On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev > , wrote: >> Hi, >> >> after all the talk about gcc versions, I tried to build gcc 8 here. >> Officially it says "gcc8 is known to fail". >> >> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit >> later, I fear my MacBook has fan issues. >> >> Intel 64bit finished build! Took several hours. I thus tried to install >> it... and it says again >> "libgcc8 is known to fail. Try to install anyway?" and yes, it just >> built! >> >> However then it asks about libgcc9 but I want to stay on libgcc8, >> that was the point... am Inheriting that it will go up to gcc13? >> >> >> On PowerPC instead build fails (and ultimate goal is to enable newer >> gccs on PPC too, where it is needed) >> >> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', >> '-fPIC', '-fpie' or '-fPIE' >> :info:build >> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: >> In member function 'gcc::jit::result* >> gcc::jit::playback::context::dlopen_built_dso()': >> :info:build >>
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
I am not a MacPorts admin, however I believe they were pretty clear that 10.6-ppc-specific fixes belong in an overlay repo, not in macports code. If you want that changed, take it up with them. I personally agree with that decision, so I abide by it, until such time as it changes. K > On Mar 29, 2024, at 04:00, Sergio Had wrote: > > > Ken, the last time you objected to having gcc10-bootstrap building for ppc on > 10.6 in gcc13 port. > Because that was extra 10 characters of code in the macro, which was too ugly > to tolerate, apparently. > (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use > clangs on any powerpc, be it released macOS or pre-released.) > > Anyway, what I suggest is the following: > > 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be > only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti > code”, which you dislike. > 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can > add tweaks I want, and restrict that port to PowerPC. Throw away everything > unneeded from there, make it easy to maintain. > > To that separate port I can add support for libc++ on PowerPC, fix IEEE > arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which > will not land into any other gcc ports, unless someone else – not me – > decides to pick that. > > As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, > wasting many hours of compilation time for nothing, and on the other hand > revbump powerpc port without causing pain to anyone else. > > I honestly hope this can keep everyone satisfied. > > I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, > since we should not have a disagreement anymore. > > >> On Mar 29, 2024, at 5:34 AM, Ken Cunningham >> wrote: >> >> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had >> anything to do with why nobody had gotten around to updating the gcc version >> used on older systems. >> >> At least, it was not anywhere on my radar. >> >> Just -- nobody did the legwork. >> >> Ken >> >> >>> On 2024-03-28, at 11:47 AM, Sergio Had wrote: >>> >>> Let me make another, final attempt to sort this out once for all and for >>> everyone on old systems. >>> >>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds >>> on 10.6 in gcc ports and my need to support those. >>> >>> That was the stopper so far, not allowing an agreement to merge. >>> >>> I may do this today itself: I have everything working for months, just need >>> to sort commits to make it readable and implement a solution for what I >>> want. >>> >>> As a bonus, you will get IEEE intrinsics in Fortran – something that never >>> existed on ppc. On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote: You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I have seen people using gcc13 on 10.5 ppc following my instructions from the PR. What is the point of gcc8? You build gcc10-bootstrap and then use it to build gcc13. Nothing else needed in between. > On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev > , wrote: > Hi, > > after all the talk about gcc versions, I tried to build gcc 8 here. > Officially it says "gcc8 is known to fail". > > I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit > later, I fear my MacBook has fan issues. > > Intel 64bit finished build! Took several hours. I thus tried to install > it... and it says again > "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! > > However then it asks about libgcc9 but I want to stay on libgcc8, > that was the point... am Inheriting that it will go up to gcc13? > > > On PowerPC instead build fails (and ultimate goal is to enable newer > gccs on PPC too, where it is needed) > > :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', > '-fPIC', '-fpie' or '-fPIE' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: > In member function 'gcc::jit::result* > gcc::jit::playback::context::dlopen_built_dso()': > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: > error: 'dlerror' was not declared in this scope > :info:build dlerror (); > :info:build ^~~ > > > Already seen this? Full build log is 6.7MB > Should I open a ticket on this or is there already one for gcc8 efforts? > didn't find it. > > Riccardo >> >
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Ken, the last time you objected to having gcc10-bootstrap building for ppc on 10.6 in gcc13 port. Because that was extra 10 characters of code in the macro, which was too ugly to tolerate, apparently. (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use clangs on any powerpc, be it released macOS or pre-released.) Anyway, what I suggest is the following: 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti code”, which you dislike. 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can add tweaks I want, and restrict that port to PowerPC. Throw away everything unneeded from there, make it easy to maintain. To that separate port I can add support for libc++ on PowerPC, fix IEEE arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which will not land into any other gcc ports, unless someone else – not me – decides to pick that. As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, wasting many hours of compilation time for nothing, and on the other hand revbump powerpc port without causing pain to anyone else. I honestly hope this can keep everyone satisfied. I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, since we should not have a disagreement anymore. > On Mar 29, 2024, at 5:34 AM, Ken Cunningham > wrote: > > I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had > anything to do with why nobody had gotten around to updating the gcc version > used on older systems. > > At least, it was not anywhere on my radar. > > Just -- nobody did the legwork. > > Ken > > > On 2024-03-28, at 11:47 AM, Sergio Had wrote: > >> Let me make another, final attempt to sort this out once for all and for >> everyone on old systems. >> >> I got an idea how to satisfy Ken’s preference of not supporting ppc builds >> on 10.6 in gcc ports and my need to support those. >> >> That was the stopper so far, not allowing an agreement to merge. >> >> I may do this today itself: I have everything working for months, just need >> to sort commits to make it readable and implement a solution for what I want. >> >> As a bonus, you will get IEEE intrinsics in Fortran – something that never >> existed on ppc. >> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote: >>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). >>> I have seen people using gcc13 on 10.5 ppc following my instructions from >>> the PR. >>> >>> What is the point of gcc8? >>> >>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else >>> needed in between. >>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev >>> , wrote: Hi, after all the talk about gcc versions, I tried to build gcc 8 here. Officially it says "gcc8 is known to fail". I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit later, I fear my MacBook has fan issues. Intel 64bit finished build! Took several hours. I thus tried to install it... and it says again "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! However then it asks about libgcc9 but I want to stay on libgcc8, that was the point... am Inheriting that it will go up to gcc13? On PowerPC instead build fails (and ultimate goal is to enable newer gccs on PPC too, where it is needed) :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', '-fPIC', '-fpie' or '-fPIE' :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: In member function 'gcc::jit::result* gcc::jit::playback::context::dlopen_built_dso()': :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: error: 'dlerror' was not declared in this scope :info:build dlerror (); :info:build ^~~ Already seen this? Full build log is 6.7MB Should I open a ticket on this or is there already one for gcc8 efforts? didn't find it. Riccardo >
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
supporting all the gcc versions between gcc 8 and 12 on older systems will be quite a bit of work and require a lot of build time for poor users of these systems. To have libgcc7, the way it is now, you need to build libgcc13, 12, 11, 10, 9, 8, and then 7. That is -- a lot of gcc building for a questionable benefit. If we could agree to use what we have (up to gcc7) and then skip to gcc13 it would be much easier. That would likely take no more than a few hours of work for some one to do, once there was consensus on it. Ken On 2024-03-28, at 8:57 AM, Riccardo Mottola wrote: > Hi, > > after all the talk about gcc versions, I tried to build gcc 8 here. > Officially it says "gcc8 is known to fail". > > I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit > later, I fear my MacBook has fan issues. > > Intel 64bit finished build! Took several hours. I thus tried to install > it... and it says again > "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! > > However then it asks about libgcc9 but I want to stay on libgcc8, > that was the point... am Inheriting that it will go up to gcc13? > > > On PowerPC instead build fails (and ultimate goal is to enable newer > gccs on PPC too, where it is needed) > > :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', > '-fPIC', '-fpie' or '-fPIE' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: > In member function 'gcc::jit::result* > gcc::jit::playback::context::dlopen_built_dso()': > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: > error: 'dlerror' was not declared in this scope > :info:builddlerror (); > :info:build^~~ > > > Already seen this? Full build log is 6.7MB > Should I open a ticket on this or is there already one for gcc8 efforts? > didn't find it. > > Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had anything to do with why nobody had gotten around to updating the gcc version used on older systems. At least, it was not anywhere on my radar. Just -- nobody did the legwork. Ken On 2024-03-28, at 11:47 AM, Sergio Had wrote: > Let me make another, final attempt to sort this out once for all and for > everyone on old systems. > > I got an idea how to satisfy Ken’s preference of not supporting ppc builds on > 10.6 in gcc ports and my need to support those. > > That was the stopper so far, not allowing an agreement to merge. > > I may do this today itself: I have everything working for months, just need > to sort commits to make it readable and implement a solution for what I want. > > As a bonus, you will get IEEE intrinsics in Fortran – something that never > existed on ppc. > On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote: >> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I >> have seen people using gcc13 on 10.5 ppc following my instructions from the >> PR. >> >> What is the point of gcc8? >> >> You build gcc10-bootstrap and then use it to build gcc13. Nothing else >> needed in between. >> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev >> , wrote: >>> Hi, >>> >>> after all the talk about gcc versions, I tried to build gcc 8 here. >>> Officially it says "gcc8 is known to fail". >>> >>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit >>> later, I fear my MacBook has fan issues. >>> >>> Intel 64bit finished build! Took several hours. I thus tried to install >>> it... and it says again >>> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! >>> >>> However then it asks about libgcc9 but I want to stay on libgcc8, >>> that was the point... am Inheriting that it will go up to gcc13? >>> >>> >>> On PowerPC instead build fails (and ultimate goal is to enable newer >>> gccs on PPC too, where it is needed) >>> >>> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', >>> '-fPIC', '-fpie' or '-fPIE' >>> :info:build >>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: >>> In member function 'gcc::jit::result* >>> gcc::jit::playback::context::dlopen_built_dso()': >>> :info:build >>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: >>> error: 'dlerror' was not declared in this scope >>> :info:build dlerror (); >>> :info:build ^~~ >>> >>> >>> Already seen this? Full build log is 6.7MB >>> Should I open a ticket on this or is there already one for gcc8 efforts? >>> didn't find it. >>> >>> Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Let me make another, final attempt to sort this out once for all and for everyone on old systems. I got an idea how to satisfy Ken’s preference of not supporting ppc builds on 10.6 in gcc ports and my need to support those. That was the stopper so far, not allowing an agreement to merge. I may do this today itself: I have everything working for months, just need to sort commits to make it readable and implement a solution for what I want. As a bonus, you will get IEEE intrinsics in Fortran – something that never existed on ppc. On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote: > You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I > have seen people using gcc13 on 10.5 ppc following my instructions from the > PR. > > What is the point of gcc8? > > You build gcc10-bootstrap and then use it to build gcc13. Nothing else needed > in between. > On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev > , wrote: > > Hi, > > > > after all the talk about gcc versions, I tried to build gcc 8 here. > > Officially it says "gcc8 is known to fail". > > > > I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit > > later, I fear my MacBook has fan issues. > > > > Intel 64bit finished build! Took several hours. I thus tried to install > > it... and it says again > > "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! > > > > However then it asks about libgcc9 but I want to stay on libgcc8, > > that was the point... am Inheriting that it will go up to gcc13? > > > > > > On PowerPC instead build fails (and ultimate goal is to enable newer > > gccs on PPC too, where it is needed) > > > > :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', > > '-fPIC', '-fpie' or '-fPIE' > > :info:build > > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: > > In member function 'gcc::jit::result* > > gcc::jit::playback::context::dlopen_built_dso()': > > :info:build > > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: > > error: 'dlerror' was not declared in this scope > > :info:build dlerror (); > > :info:build ^~~ > > > > > > Already seen this? Full build log is 6.7MB > > Should I open a ticket on this or is there already one for gcc8 efforts? > > didn't find it. > > > > Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). I have seen people using gcc13 on 10.5 ppc following my instructions from the PR. What is the point of gcc8? You build gcc10-bootstrap and then use it to build gcc13. Nothing else needed in between. On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev , wrote: > Hi, > > after all the talk about gcc versions, I tried to build gcc 8 here. > Officially it says "gcc8 is known to fail". > > I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit > later, I fear my MacBook has fan issues. > > Intel 64bit finished build! Took several hours. I thus tried to install > it... and it says again > "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! > > However then it asks about libgcc9 but I want to stay on libgcc8, > that was the point... am Inheriting that it will go up to gcc13? > > > On PowerPC instead build fails (and ultimate goal is to enable newer > gccs on PPC too, where it is needed) > > :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic', > '-fPIC', '-fpie' or '-fPIE' > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: > In member function 'gcc::jit::result* > gcc::jit::playback::context::dlopen_built_dso()': > :info:build > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: > error: 'dlerror' was not declared in this scope > :info:build dlerror (); > :info:build ^~~ > > > Already seen this? Full build log is 6.7MB > Should I open a ticket on this or is there already one for gcc8 efforts? > didn't find it. > > Riccardo
