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.
Py ports maintainers: FYI "Enforcing consistent metadata for [Python] packages"
FYI for anyone involved with maintaining Python-related ports in MacPorts: Over in discuss.python.org, Paul Moore started a thread on "Enforcing consistent metadata for packages". I am naive about Python packaging, so most of it goes over my head. But this comment caught my eye: Linux distributors routinely patch sdists and build their system packages from the resulting wheels. This patching will, /by design/, violate the consistency rules we’re discussing. How do we handle this? Might some Python-related ports also patch sdists? Might those ports violate the discussed consistency rules? By design? If so, maybe those port maintainers might be able to contribute to the thread by sharing the MacPorts experience. For Your Information only. If there is no issue, apologies for taking up airtime with it. -- . --Jim DeLaHunt,j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant, Vancouver, B.C., Canada
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
