> On Nov 20, 2024, at 05:45, Chris Jones via macports-dev
> <[email protected]> wrote:
>
> Hi,
>
> Personally, I object to the idea of removing (perfectly functional) compiler
> options from users, the vast majority of which will get them via the binary
> tarballs and thus the dependency chain is not an issue (the libgccN ports are
> very light weight, once built) just to cater to the needs of a very small
> (but at times vocal ;)) sub-set of users running completely outdated OSes.
>
> To give a more concrete example, in your list you drop gcc 11-13. Now, we
> already know gcc14 has certain nuances what means some things have issues. So
> I can easily imagine some users being somewhat inconvenienced by dropping
> gcc13, which is working just fine.
>
> So if you do this, please follow your suggestion of *only* dropping them on
> these ancient OSes where you want to limit the build deps. For the other OSes
> I request the flexibility of offering all major GCC versions is kept.
>
> Chris
>
Status quo is easiest, but this would mean ongoing os-version differences for
ports that offer gcc variants. And supporting 15 gcc versions is a pain.
Was hoping to see a tight way of keeping all the ports that use gcc simpler and
coherent, but if there truly is some reason for these non-current gccs to get
ongoing support in macports, I guess we are stuck.
Any concrete example of something gcc-14 breaks that gcc-13 builds?
>> On 20/11/2024 1:17 pm, Ken Cunningham wrote:
>> Hi Riccardo, yes need your input!
>> Reasoning for list I offerred:
>> apple-gcc42 stays, of course. unique and needed on 10.4
>> gcc4.8 … tenfourfox
>> gcc5 … for the java compiler used in pdftoolkit on older systems
>> gcc7 … current default compiler used for 5 years now on 10.4/5, well known,
>> but staring to be a few things it can’t build, hence the pressure to upgrade
>> gcc10 .. last one that builds without c++11 … little used, but we need a
>> fallback about here, so this is a guess as to a good fallback
>> gcc14 … current, has been used for the past year or so as the default
>> compiler on ppc (by a small number of people TBH)
>> If this is to be useful and worth doing, the list needs to be shortish.
>> Another could be added later I suppose, but would be some pain.
>> All others would be dropped, (except the bootstraps) as anything they built
>> would potentially ABI breaking due to mismatched libs.
>>>> On Nov 20, 2024, at 02:16, Riccardo Mottola <[email protected]>
>>>> wrote:
>>>
>>> Hi Ken,
>>>
>>> I think in the past, I asked for something similar.
>>>
>>> Two questions:
>>> 1) if a user wants a compiler beyond the "golden list"? will you remove the
>>> ports alltogether or will it just mean for him more compilation because it
>>> builds another libgcc?
>>> 2) can we start with a minimal list and then "tweak" things if we discover
>>> some software not building and add e.g. one or two versions later?
>>>
>>> Ken Cunningham wrote:
>>>> The list of uniquely useful gcc compilers might be as short as:
>>>>
>>>> gcc-4.8, gcc5, gcc7, gcc10, and gcc-14.
>>>>
>>>> All those already build on the older systems, and are at least a
>>>> manageable list of versions to maintain.
>>>>
>>>> Could we ask for thoughts and possible get consensus that the list of gcc
>>>> compilers supported by MacPorts be shortened to a list such as that?
>>>
>>> Making this list is I think a trade-off between a newer compiler breaking
>>> old code and capability of also compiling newer software.
>>>
>>> My favorite is usually:
>>>
>>> gcc4.8 (very good for old stuff... very stable everywhere and never found
>>> the need to use gcc 4.2 instad of gcc 4.8 except to stick with apple
>>> versions)
>>> gcc 6.5 : best "classic" compiler on 10.5/10.6, reliable, definitely to be
>>> included in list
>>> gcc 8 : first "modern" compiler
>>>
>>> and then... gcc12 or 13 just because I used them long time and gcc14 is
>>> new, undecdided about which to choose
>>>
>>> I think gcc5 can be dropped.. either 4.8 or 6.5 should do
>>>
>>> gcc7 has been for a year the newest compiler on 10.5 for me, but can it be
>>> replaced by 6.5 or gcc8?
>>>
>>> gcc10: could we try do drop it and have latest?
>>> gcc14 - I have used it very little on MacOS - but I do on linux and it is
>>> very finky...
>
