From owner-freebsd-ports@freebsd.org Thu Feb 21 18:30:47 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 D0DC614EB618 for ; Thu, 21 Feb 2019 18:30:47 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id A7E3C873BF; Thu, 21 Feb 2019 18:30:46 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (artemis.db.net [45.32.229.41]) by artemis.db.net (Postfix) with ESMTP id 8976010253; Thu, 21 Feb 2019 18:30:43 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id 18A9139875; Thu, 21 Feb 2019 13:30:41 -0500 (EST) Date: Thu, 21 Feb 2019 13:30:41 -0500 From: Diane Bruce To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Diane Bruce , "Russell L. Carter" , FreeBSD Ports ML , Eugene Grosbein Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190221183040.GA42303@night.db.net> References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.11.1 (2018-12-01) X-Rspamd-Queue-Id: A7E3C873BF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.51 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.80)[0.798,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[db.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.789,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mx1-us2.ppe-hosted.com]; NEURAL_SPAM_LONG(0.80)[0.798,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:45.32.224.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.14)[asn: 20473(0.75), 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:30:48 -0000 On Thu, Feb 21, 2019 at 06:05:15PM +0100, 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. Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed a specific port will require a fortran built binary module later. > > Maybe we should compile *all* ports with gcc rpaths without depending > on gcc, just like we already compile everything with -fstack-protector > in LDFLAGS. > > There's also the fact that gfortran behaves differently from the C > compilers (both clang and gcc) when it comes to libgcc_s. Gfortran > always links with libgcc_s. The C compilers link with libgcc.a first > and then with libgcc_s only as needed. This eliminates almost all What is really happening is gfortran links with libgfortran (surprise surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > links with libgcc_s. The only ones left are for exception handling > and stack unwinding and gcc libgcc_s and base system libgcc_s are > version compatible for that so it doesn't matter which one gets picked > up. The attached patch for lang/gcc8 makes gfortran behave just like > the C compilers. Something like this was tried already. I'll have to dig into my old notes. > > We cannot rename the base system libgcc_s to libclang_s because then a > process could load both gcc libgcc_s and base system libclang_s and I > think that could break exception handling and stack unwinding in weird > ways. Yes yes and yes. It would be a right PITA. Perhaps it could be done with some weak symbols but personally I think that's another hack. I'll go look for whatever symbols we are missing and see if we can fix our libgcc_s ... Diane -- - db@FreeBSD.org db@db.net http://artemis.db.net/~db