From owner-freebsd-ports@freebsd.org Thu Feb 21 18:25: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 7842B14EB2A3 for ; Thu, 21 Feb 2019 18:25: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 8D16186F7B; Thu, 21 Feb 2019 18:25:09 +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 x1LIOreb082929 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 21 Feb 2019 10:24:53 -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 x1LIOp01082928; Thu, 21 Feb 2019 10:24:51 -0800 (PST) (envelope-from sgk) Date: Thu, 21 Feb 2019 10:24:51 -0800 From: Steve Kargl To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Diane Bruce , "Russell L. Carter" , Eugene Grosbein , FreeBSD Ports ML Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190221182451.GA82216@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> 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.2 (2019-01-07) X-Rspamd-Queue-Id: 8D16186F7B X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.31 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.79)[0.788,0]; NEURAL_SPAM_MEDIUM(0.70)[0.697,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)[troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_LONG(0.06)[0.063,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:25:11 -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. > > 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. libgfortran is gfortran's runtime library. libgcc.a is gcc's runtime library. The link orders are the same: libgfortran then libgcc_s; libgcc then libgcc_s > This eliminates almost all > 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. Just add -static to FFLAGS. Yep, you're building static libraries. > 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. Wouldn't that be a bug in the program that loads both? BTW, if you compare gcc trunks symbol map ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map with src/lib/libgcc_s/Version.map, you'll find that that maps are no one-to-one. As anyone tried adding an empty sections to FreeBSD's libgcc_s, /* * Empty sections to work around FreeBSD abusing the name * of a well-known GCC library. */ GCC_4.6.0 { } GCC_4.3.0; GCC_4.7.0 { } GCC_4.6.0; GCC_4.8.0 { } GCC_4.7.0; GCC_7.0.0 { } GCC_4.8.0; -- Steve