Date: Sat, 28 Oct 2017 13:40:45 -0300 From: Joseph Mingrone <jrm@FreeBSD.org> To: Tijl Coosemans <tijl@FreeBSD.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, portmgr@FreeBSD.org Subject: Re: svn commit: r452962 - head/math/libRmath Message-ID: <86efpntecy.fsf@phe.ftfl.ca> In-Reply-To: <20171028182237.1f83708c@kalimero.tijl.coosemans.org> (Tijl Coosemans's message of "Sat, 28 Oct 2017 18:22:48 %2B0200") References: <201710270052.v9R0qf7A058644@repo.freebsd.org> <20171027125130.39e98c9c@kalimero.tijl.coosemans.org> <86d158vcve.fsf@phe.ftfl.ca> <20171028124843.56f8e8d3@kalimero.tijl.coosemans.org> <86y3nvtjlt.fsf@phe.ftfl.ca> <20171028182237.1f83708c@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tijl Coosemans <tijl@FreeBSD.org> writes: > On Sat, 28 Oct 2017 11:47:26 -0300 Joseph Mingrone <jrm@FreeBSD.org> wrot= e: >> Tijl Coosemans <tijl@FreeBSD.org> writes: >>> On Fri, 27 Oct 2017 12:17:41 -0300 Joseph Mingrone <jrm@FreeBSD.org> wr= ote:=20=20 >>>> Tijl Coosemans <tijl@FreeBSD.org> writes:=20=20 >>>>> I don't see this approach to support flang work. Will this have to be >>>>> added to all Fortran ports? Will you modify all Fortran ports whenev= er >>>>> flang supports a new architecture? Will users run into problems when >>>>> they select gfortran in some ports and flang in others? Will you all= ow >>>>> port maintainers to set different defaults in their ports? It all lo= oks >>>>> like high maintenance and highly error prone. Too many modifiable >>>>> variables in too many places.=20=20=20=20 >>>>> USES arguments are the wrong mechanism for this in my opinion. >>>>> DEFAULT_VERSIONS seems much better to me. Users can then add >>>>> fortran=3Dgfortran or fortran=3Dflang to DEFAULT_VERSIONS. fortran.m= k would >>>>> look at FORTRAN_DEFAULT to determine the fortran compiler instead of >>>>> fortran_ARGS. All ports would simply have USES=3Dfortran and no opti= ons. >>>>> That's two variables in two locations: the user's DEFAULT_VERSIONS in >>>>> make.conf and the ports tree FORTRAN_DEFAULT in bsd.default-versions.= mk >>>>> (which could eventually be set to flang on amd64 if that turns out to= be >>>>> a better default). Advanced users that want to build some ports with >>>>> flang and some with gfortran and think they know what they're doing c= an >>>>> figure out the if-elseif-else logic needed in their make.conf. Port >>>>> maintainers/committers should not have to deal with the support reque= sts >>>>> resulting from such mixed configurations which is very likely if you >>>>> add per port options like you do in this commit.=20=20=20=20 >>>> The DEFAULT_VERSIONS solution is cleaner, but switching all Fortran >>>> ports to build with flang would cause breakage and, as you know, flang >>>> is currently only available for amd64. The current, more complicated, >>>> fine-tuned approach is less drastic. If port maintainers do not make >>>> any changes, nothing with their port changes. They have time to test >>>> with flang and make a choice to opt in. For example, math/R defaults = to >>>> flang (on amd64) because we have problems with gfortran [1][2] and a >>>> work-in-progress port for Rstudio [3] only works when math/R uses flan= g. >>>> Hopefully flang will mature and become supported on more architectures, >>>> port maintainers will put in some work to support flang, and it will be >>>> an obvious choice to move to the DEFAULT_VERSIONS approach. This is n= ot >>>> a precedent for choosing the compiler as a port option [4].=20=20 >>>> [1] https://wiki.freebsd.org/libgcc%20problem >>>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220359 >>>> [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221127 >>>> [4] E.G. cad/ghdl games/eduke32 lang/erlang-runtime16 lang/gambit-c >>>> math/opensolaris-libm multimedia/x264 net-p2p/cpuminer net/asteris= k11 >>>> www/mod_spdy=20=20 >>> The download problem you have in math/R looks like the problem reported= at >>> https://lists.freebsd.org/pipermail/freebsd-current/2017-August/066855.= html >>> https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067254= .html >>> and is unrelated to Fortran.=20=20 >> Thanks for this. The problem is with gfortran (gcc). It is good to >> know it is simply with gcc/gfortran and not a result of mixing libgcc >> libraries. The main point for users of math/R is that problems are only >> triggered when it is built with gfortran and not with flang. If we want >> R to work as it should, we need flang, but if we have to switch all >> Fortran ports to flang we will break (many) other ports. > It's not a gfortran problem. It's a kernel or libthr problem. You can > work around it by avoiding the combination of recycled thread stacks and > exception handling done by ports libgcc_s. When you switched from curl > to wget you avoided threads and that fixed the problem. Switching to > flang avoids ports libgcc_s and that also fixes the problem, but it's not > necessary to go this way. You could probably go back to curl if you > build it with the CARES option instead of THREADED_RESOLVER. >>> You could then ask portmgr for an exp-run with the default set to >>> flang to see where the problems are. Point upstream flang developers >>> and anyone else who wants to push flang to the error logs and >>> prioritise fixing ports that cause the biggest fallout. You'll get >>> better results faster that way than when you expect individual port >>> maintainers to experiment with flang or fix flang related issues.=20=20 >> I did this with a private poudriere run and there was a lot of breakage >> with flang. It was a few months ago though, so I will try again. If a >> high proportion break with flang, then I still feel it might be best (in >> terms of breakage for users) to ease in with the current approach. I >> will report back soon(ish). > If it's really that bad then flang is not ready and it's somewhat > irresponsible to use it for such an important package as R. Flang has > no proven track record. Even if it builds without errors in case of R > you can't be reasonably sure it produces correct code. With compilers > you have to be a bit more conservative and cautious than usual because > everything else depends on it. I agree, and that's exactly why I am hesitant to make a change that could result in all ports being built with flang. But, let's see what the results look like for the poudriere run. I use R daily. I tested by running R built with flang for something like a month before making the switch. And, I only made the switch when it was clear that downloading R packages was broken when R was built with gfortran. I think the R port/package has improved over the past year or so, but if you think the changes have been irresponsible, I am willing to transfer maintainership. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEVbCTpybDiFVxIrrVNqQMg7DW754FAln0sw1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUACgkQNqQMg7DW 7564fhAAiQ+dmtuf3iLRYWiJjFs7M3ACGviPeDUEO1BYj9cloxK7knjfuWj9E4Jl 9LrTcCZn1CTWdchFjNtHuwBowbKE2pAk+qlgksOZkB1akOdUPve0Ijxb4uBG4+bZ 4VqlK5SJjhP+4qwWoCHAm5tUU0iLnuSqEIwF+NoZUCk7BqHm2+UoZpA7BTTv4sK2 01aZiTy7GjFVWYSqM/9kX++SAJH1xvmAPGp97XQKUwMPxcVJGVUwBEHnHVx8ODkz Zh+WGhXnofXbmzPIgImxvKo0+PhvBpAr8+rHL3cDQvVzXKHImbklOEyMsCK1SaCs Aq3+3MUgTM+liXSLZ0C9Y1aWpfIL67BTLpCrWQu84ZXlBxD/mYv4/OUrlRFAArUY qlDTbWWjVLbmPK2p08XB5K1EABLjVwgoNhNMTZ+J/tUmgOHZ9tTzSh7esUArU5l7 GcX34JT66h+9UoaIc2Fd/OEfIYaf9uZt1cAAU3OdBhNgQpjQqZtrkEKDLeEllKIp qO9/o8ita+khBnF3+AxEOYbFOeMXR8Sls7oszFakGeZ6gGmXuu/AiEIvDau9ygq9 88/BU+PcPP2Tuo8b05TMUJxfAzHN2g4WShK+/Q62aFwo4at+yVS257f2D4nk7y6z H0bGev12R9VPNiYKRAwlP6hmGCjOb2JxrqEZI6IH5yTJduIAvyw= =6j6c -----END PGP SIGNATURE----- --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86efpntecy.fsf>