tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: compiler.mk nits



nia <nia%NetBSD.org@localhost> writes:

> On Tue, Jan 02, 2024 at 06:50:47PM -0500, Greg Troxel wrote:
>> While improving a comment in gcc.mk, which explains that we tend to gcc
>> 5/7/10 as shipped in NetBSD 8/9/10, I noticed:
>> 
>>   The base GCC_REQ is 3.0.0 if we need c99 or x86_64 and 2.8.0
>>   otherwise.
>> 
>>     - Probably this should be "if not i386" rather than "if x86_64".
>> 
>>     - I guess it's good for retrocomputing to not object if the base
>>       system is 2.8.0 and we are building a package that only needs c,
>>       on i386.  But maybe we should gc the if and just say 3.0.0.
>>
>
> I think gcc3 even is inclusive of Solaris 8.
> But I think OpenBSD shipped 2.8.0 way past its use-by date.

I guess the question is whether any release of OpenBSD with 2.8.0 is new
enough for it to be reasonable to expect to use the base compiler with
pkgsrc-current, without having to build a new gcc, for any real
scenarios.  I suspect that's "zero actual benefit to zero actual
people".  But the if doesn't really hurt.

>>   We ask for 4.9 for c11, cxx:unique_ptr and cxx:regex.  This violates
>>   the general "align to releeas" rule.  I could see us doing one of the
>>   following:
>> 
>>     - change to 5 with a comment that 4.9 would work
>> 
>>     - add a comment that we are staying with 4.9 instead of the plan
>>       that says 5 because we don't want to burden systems with 4.9 that
>>       only need this
>> 
>>   Same for cxx:charconv which requires gcc 8.  Comment, change to 10
>>   with comment, something else?
>
> Enterprise Linux 8 has gcc 8.
>
> I mostly see value in the "align to releases" rule for C++,
> for c11 I'm a lot less enthusiastic. I would like to not reject 4.9
> for c11, the usual issues with C++ compilers don't apply. I am also
> retrocomputing and remember 5.x being problematic for whatever reason.

OK, will add comments.


This also reminds me that the "require things in releases" while an
improvement over what was there -- things are vastly better than they
were a year ago thanks to your overhaul -- isn't really the right thing.
Instead we should:

  require what is required

  on each platform, if an upgraded compiler is needed, jump to a small
  number of versions that are aligned with that platform's releases.

But that's more work.  I have kludged it locally for my netbsd-9 systems
to jump to gcc10 and will see how that goes.




Home | Main Index | Thread Index | Old Index