From nobody Sun Nov 20 22:08:04 2022 X-Original-To: dev-commits-ports-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NFl5N289kz4hTZ5; Sun, 20 Nov 2022 22:08:08 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NFl5N1dScz3Nnr; Sun, 20 Nov 2022 22:08:08 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668982088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZTEW415dY8luRdnyYz5w7lbwPXleeeL6IBDgmT6500E=; b=Gym2d8Ao89kEJ2YSFl/O9pQD5ztNdIbPcSYHE+o8DWS5AM/KOGbKKerkUFolE81PGo3sel J4qN70N9gfVS9yOwPhwFzdUDxfOEGW6WANQMkadiXUR5bL4sOYHm2siaIkY8nI83ZvWTG4 jd5TbTg6odBxp5v/3tpr1zTogjbL71oWs8SNxkjgqwWXu4cqO2jzVPXkAxCm+yvldEdrfo FROhsmn37cRh0bAQQtGCg8l9aQ8Pvdn4LfrdGy8PZJHiFCt9sxHLCBbfR6su9y9InEvZZ+ SSiQJyUp03WrYvVXvLmUd8sgyr0LSPS5/ZABiMUeE0Z+ooR9jUy9v+3TwiTsAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668982088; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZTEW415dY8luRdnyYz5w7lbwPXleeeL6IBDgmT6500E=; b=rMpkoQuZyStWqsx3YGwxK4iLMTFJvJsei/JWCctKRTSkNmonmfCz794F4wHbq4RlqqjZY/ H27F0ciOUDMJ9xaQD68IrnaKgx4bYWy6rbkBJLyicBUypUUNwaIfilbcsDEqZBQsohlM49 7B4c2msdTpA3CHVQYUzS70+xFnf7JTNBwHWozxilyZ4wRQ8f4XP74yn0wBvy90jeih+kLv mtmo7sLXMa84V0hqhdCq0+MvQcx+DpFdsmIcuFE0AJArEjF2qjFl7pb2aCZne+JPWgUY6x kuAROxQzlui/Ar1p09n7EHeQJ9wDPKpNojJDlFrzGFnOOILZEuU+roAHaI7IFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668982088; a=rsa-sha256; cv=none; b=uCn++FmObfuGcOa7lgGJ//cBOE3X4dCQV4T1oQgNstuflEJ1Xr2HELOrGsC7ZIXVAWQX09 yL/xB8N09fh8SE06fwE26Be5btXjGO4DqYusnCfbMxNEG/FmB1LFcB9R+w2KW2iITj4k/D wv8Fq2JnDbm7ffVmKQchcVqQfQJReoiaKXCeXaJ9dhzeuBZChONXHRa8mWsVEaa62akt1N kxtXxSeIUDZDJPy1UOIBJcw9PNkCErzUStWwPMBMJjKReUSL3pcOr1x/1lb2GIr7ExY/Pb 87hyNt+Vl2496Of4iptdtt3QqDPGUIGa2eb+hastO30Ulf1S4ao1fQFYD3Q+3w== Received: from hal.tijl.coosemans.org (unknown [IPv6:2a02:a03f:894b:4700:78ec:c60a:a07c:c361]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NFl5M12t6zygM; Sun, 20 Nov 2022 22:08:07 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Sun, 20 Nov 2022 23:08:04 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Lorenzo Salvadore Cc: thierry@FreeBSD.org, yuri@FreeBSD.org, ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org, Gerald Pfeifer Subject: Re: git: 4191c71fbd22 - main - Mk/Uses/fortran.mk: Make gfortran respect USE_GCC Message-ID: <20221120230804.68f85484@hal.tijl.coosemans.org> In-Reply-To: References: <202211162139.2AGLdojd006463@gitrepo.freebsd.org> <20221118204110.5ff6c228@hal.tijl.coosemans.org> List-Id: Commits to the main branch of the FreeBSD ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-main@freebsd.org X-BeenThere: dev-commits-ports-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Nov 2022 21:45:18 +0000 Lorenzo Salvadore wrote: > On Friday, November 18th, 2022 at 8:41 PM, T=C4=B3l Coosemans wrote: >> On Wed, 16 Nov 2022 21:39:50 GMT Lorenzo Salvadore >> salvadore@FreeBSD.org wrote: >>> The branch main has been updated by salvadore: >>>=20 >>> URL: https://cgit.FreeBSD.org/ports/commit/?id=3D4191c71fbd229e5a96382b= c6fa271a1ce5668b0f >>>=20 >>> 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 >>>=20 >>> Mk/Uses/fortran.mk: Make gfortran respect USE_GCC >>>=20 >>> Allow choosing a specific version of gfortran through USE_GCC variable. >>>=20 >>> PR: 266196 >>> Approved by: thierry (fortran) >>> Co-authored by: thierry >>> --- >>> Mk/Uses/fortran.mk | 4 ++++ >>> 1 file changed, 4 insertions(+) >>>=20 >>> 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=3D ${FORTRAN_DEFAULT} >>> . endif >>>=20 >>> . if ${fortran_ARGS} =3D=3D gfortran >>> +. if empty(USE_GCC) >>> _GCC_VER=3D ${GCC_DEFAULT:S/.//} >>> +. else >>> +_GCC_VER=3D ${_USE_GCC} >>> +. endif >>> BUILD_DEPENDS+=3D gfortran${_GCC_VER}:lang/gcc${_GCC_VER} >>> RUN_DEPENDS+=3D gfortran${_GCC_VER}:lang/gcc${_GCC_VER} >>> F77=3D gfortran${_GCC_VER} =20 >>=20 >> 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. =20 >=20 > 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 fin= e. > Moreover, if for some fortran dependent port it is better to ignore USE_G= CC, > it is sufficient to set USE_GCC=3Dyes 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=3D with USE_GCC=3Dyes. And t= he 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: >>=20 >> .if ${GCC_DEFAULT} !=3D 11 >> IGNORE=3D This port only works with gcc 11. You can add DEFAULT_VERSIONS= +=3Dgcc=3D11 to /etc/make.conf >> .endif =20 >=20 > I think this is a bad idea as: > - it prevents the port to be built on the official packages builder as so= on as > GCC_DEFAULT gets updated to 12, so that users that prefer to install soft= ware > from packages only cannot install science/octopus anymore; > - adding DEFAULT_VERSIONS+=3Dgcc11 to /etc/make.conf would change the dep= endencies > of all the gcc dependent ports, not just science/octopus. This could gene= rate > 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=3D 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.