Re: git: 4191c71fbd22 - main - Mk/Uses/fortran.mk: Make gfortran respect USE_GCC

On Fri, 18 Nov 2022 21:45:18 +0000 Lorenzo Salvadore
<developer@lorenzosalvadore.it> wrote:
> On Friday, November 18th, 2022 at 8:41 PM, Tijl Coosemans <tijl@FreeBSD.org> wrote:
>> On Wed, 16 Nov 2022 21:39:50 GMT Lorenzo Salvadore
>> salvadore@FreeBSD.org wrote:
>>> The branch main has been updated by salvadore:
>>> 
>>> URL: https://cgit.FreeBSD.org/ports/commit/?id=4191c71fbd229e5a96382bc6fa271a1ce5668b0f
>>> 
>>> commit 4191c71fbd229e5a96382bc6fa271a1ce5668b0f
>>> Author: Lorenzo Salvadore salvadore@FreeBSD.org
>>> AuthorDate: 2022-11-16 14:43:40 +0000
>>> Commit: Lorenzo Salvadore salvadore@FreeBSD.org
>>> CommitDate: 2022-11-16 21:38:54 +0000
>>> 
>>> Mk/Uses/fortran.mk: Make gfortran respect USE_GCC
>>> 
>>> Allow choosing a specific version of gfortran through USE_GCC variable.
>>> 
>>> PR: 266196
>>> Approved by: thierry (fortran)
>>> Co-authored by: thierry
>>> ---
>>> Mk/Uses/fortran.mk | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>> 
>>> diff --git a/Mk/Uses/fortran.mk b/Mk/Uses/fortran.mk
>>> index 09ebd62b1a0f..d335fad4dc8e 100644
>>> --- a/Mk/Uses/fortran.mk
>>> +++ b/Mk/Uses/fortran.mk
>>> @@ -14,7 +14,11 @@ fortran_ARGS= ${FORTRAN_DEFAULT}
>>> . endif
>>> 
>>> . if ${fortran_ARGS} == gfortran
>>> +. if empty(USE_GCC)
>>> _GCC_VER= ${GCC_DEFAULT:S/.//}
>>> +. else
>>> +_GCC_VER= ${_USE_GCC}
>>> +. endif
>>> BUILD_DEPENDS+= gfortran${_GCC_VER}:lang/gcc${_GCC_VER}
>>> RUN_DEPENDS+= gfortran${_GCC_VER}:lang/gcc${_GCC_VER}
>>> F77= gfortran${_GCC_VER}  
>> 
>> When I wrote this file I didn't include this because users will end up
>> with multiple versions of GCC installed, each with its own set of runtime
>> libraries. So they'll have programs/libraries built against different
>> runtime libraries and those don't always work together. For instance,
>> science/octopus is now built with GCC 11 but its dependencies like
>> lapack are built with GCC 12. These dependencies may require features
>> from GCC 12 runtime libraries while science/octopus programs probably
>> (I haven't checked) load GCC 11 runtime libraries when you run them.  
> 
> I do not think it is a big issue if multiple versions of GCC are installed
> at the same time. Indeed, USE_GCC exists since a long time and while a few
> bugs might arise sometimes, they get fixed eventually and things work fine.
> Moreover, if for some fortran dependent port it is better to ignore USE_GCC,
> it is sufficient to set USE_GCC=yes and things work just as before this commit.

It's not causing as much trouble as it used to because gerald@ put in
quite some effort to replace USE_GCC=<version> with USE_GCC=yes.  And the
base system switching from old GCC to Clang allowed many ports to drop
USE_GCC.  So today there's fewer ports that depend on GCC and they tend
to depend on the default version, but this has only reduced the number
of situations in which the problem might appear.  The problem itself
isn't gone.  It's still problematic to have ports depend on multiple
versions of GCC.  Bug reports related to GCC runtime libraries tend to
have long comment threads because they are often difficult to solve.  It
really is a class of bugs to avoid.

>> Even if this happens to work now it may not work when the default
>> switches to 13. I believe it's better for ports like science/octopus to
>> have something like this in their Makefile:
>> 
>> .if ${GCC_DEFAULT} != 11
>> IGNORE= This port only works with gcc 11. You can add DEFAULT_VERSIONS+=gcc=11 to /etc/make.conf
>> .endif  
> 
> I think this is a bad idea as:
> - it prevents the port to be built on the official packages builder as soon as
> GCC_DEFAULT gets updated to 12, so that users that prefer to install software
> from packages only cannot install science/octopus anymore;
> - adding DEFAULT_VERSIONS+=gcc11 to /etc/make.conf would change the dependencies
> of all the gcc dependent ports, not just science/octopus. This could generate
> more issues: what if a port does not build with GCC 11 but needs GCC 12+ instead?

Yes, these are the downsides, but I would say this puts some pressure on
maintainers to make sure their port works with the default, while adding
USE_GCC=<version> puts the burden on users and bug fixers because the
package may build but you don't know if it runs.  To be clear, I don't
think the burden should be on you.  If you want to bump GCC_DEFAULT you
should be allowed to add a conditional IGNORE (or even BROKEN) to ports
without a solution in sight.  The only other clean way I can think of is
to use flavors like the ports that depend on python but I think that's
overkill and would put too much burden on the package build cluster.