From owner-svn-ports-head@freebsd.org Sat Oct 28 16:40:49 2017 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5342E47A9D for ; Sat, 28 Oct 2017 16:40:49 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72DCC745F7 for ; Sat, 28 Oct 2017 16:40:49 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: by mail-qk0-f170.google.com with SMTP id f199so11747400qke.2 for ; Sat, 28 Oct 2017 09:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=o+Dm19xg8/J3nyML1MVlywYnHtGg+8nEeJ7cDBDUG8I=; b=tUxaGAMS53gM1AfuvYdqzpPbNLHe9scDb4jQd3MvThHmhaa+0mCa2P/ht1vmo/Qmil v6/5tqFlOsOjxhkSznJVCtTeMcBVjePsBiY7a9usebzoZph1hQaurfuBiei8owuPyChJ 2af4EhKqpEYyYe8PbFdTJLhS3y/DPUufakJGRV1soGU4nYAL8d6M519+5DgT2CeQUmI0 tjwQzzSUgifJOgjASJmgXLUe+2FAjGGaE+S8OjdtlfkpruYFF4UbS7N8c+c6FGlyknfN mUTgwjudM38/eehTSMcWU2ln2JbzCHe8uFHi7WLmyMaZS95+nZ7oxCq3qFCeZYzqEHpO SX5g== X-Gm-Message-State: AMCzsaW1kRN+4HxtVGipyi4SBPOccc5iTfxKIuzgaIqs/KudqohWwrnD rVBCis6XWlSLHRipDMJPCjujPQ== X-Google-Smtp-Source: ABhQp+Rm8v1Z7ZPVzUQO20X5vo1cdhQ62AGrpnpZgHTPuTmGv/9gOyy8fvFr6ZC+Zis24Nn5JevjwA== X-Received: by 10.55.41.226 with SMTP id p95mr6153671qkp.336.1509208847420; Sat, 28 Oct 2017 09:40:47 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (hlfxns017vw-142-68-134-140.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.134.140]) by smtp.gmail.com with ESMTPSA id o27sm7039837qkh.80.2017.10.28.09.40.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 28 Oct 2017 09:40:46 -0700 (PDT) From: Joseph Mingrone To: Tijl Coosemans 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 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> Date: Sat, 28 Oct 2017 13:40:45 -0300 In-Reply-To: <20171028182237.1f83708c@kalimero.tijl.coosemans.org> (Tijl Coosemans's message of "Sat, 28 Oct 2017 18:22:48 +0200") Message-ID: <86efpntecy.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:40:49 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tijl Coosemans writes: > On Sat, 28 Oct 2017 11:47:26 -0300 Joseph Mingrone wrot= e: >> Tijl Coosemans writes: >>> On Fri, 27 Oct 2017 12:17:41 -0300 Joseph Mingrone wr= ote:=20=20 >>>> Tijl Coosemans 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----- --=-=-=--