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
Two of the libgccs are stubs, the rest are not.
so it is pretty much as bad as it looks.
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
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
> 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
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
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
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.
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
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
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
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
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
13 matches
Mail list logo
