From owner-freebsd-ports@freebsd.org Thu Feb 21 18:44:11 2019 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF91E14EC180 for ; Thu, 21 Feb 2019 18:44:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE3F5881AE; Thu, 21 Feb 2019 18:44:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1LIi1eV083162 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Feb 2019 10:44:01 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1LIhwl8083149; Thu, 21 Feb 2019 10:43:58 -0800 (PST) (envelope-from sgk) Date: Thu, 21 Feb 2019 10:43:58 -0800 From: Steve Kargl To: "Russell L. Carter" Cc: =?utf-8?Q?T=C4=B3l?= Coosemans , Diane Bruce , Eugene Grosbein , FreeBSD Ports ML Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190221184358.GB82216@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <092b17f0-6fbf-662e-1061-403442248abd@pinyon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <092b17f0-6fbf-662e-1061-403442248abd@pinyon.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: DE3F5881AE X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.41 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.850,0]; NEURAL_SPAM_MEDIUM(0.70)[0.704,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_LONG(0.10)[0.096,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.07)[ip: (0.13), ipnet: 128.95.0.0/16(0.19), asn: 73(0.09), country: US(-0.07)] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 18:44:12 -0000 On Thu, Feb 21, 2019 at 10:53:00AM -0700, Russell L. Carter wrote: > On 2/21/19 10:05 AM, Tijl Coosemans wrote: > > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >>> So I must dig deeper. Perhaps with rpaths interacting with the system > >>> paths? > >> > >> You got it. ;) > >> Except python doesn't have an rpath which is why this keeps coming > >> up over and over again. > > > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > > without depending on gcc. Then python should use gcc libgcc_s when > > it exists and fall back to base system libgcc_s when it doesn't. > > > > Maybe we should compile *all* ports with gcc rpaths without depending > > on gcc, just like we already compile everything with -fstack-protector > > in LDFLAGS. > > > > > I would like to briefly present the perspective from a user's POV. > There is a large world wide population of scientific custom code > users/coders who run on linux boxes in a wide variety of > configurations. Almost none of that code will ever have a chance of > ending up in /usr/ports, although there is nothing technically > challenging about almost any of it (the porting process that is). So > anytime any of those users wants to try running their non-ported > scientific code, a large fraction of which contains python and/or > gfortan code, they are going to hit the libgcc_s issue. Only a few of > those people understand rpaths as well as I do (and I'm no expert), > because it's never been their job. They probably struggle to figure > out what question to ask, because, "libgcc_s? WTF?, this is python!" > In addition, oftentimes people have sometimes big pipelines of > different programs executing. So writing a shell script wrapper > around each and every one of those custom programs... not going to > happen. libmap.conf(5)? Not going to happen. Linux works out of the > box. > > People like Steve Kargl and me are... puzzled at why FreeBSD would > do this to itself. Having people writing and running custom > opensource software on a performant opensource OS is **good**. We > should be enabling them. I'm not puzzled. I am amused! As a long time gfortran contributor and maintainer, and probably one of the few people who regularly builds and tests gfortran on FreeBSD, it is entertaining to see the emails about the issue. I particularly like the emails that suggest that this is a gfortran problem. It is not. -- Steve