From owner-freebsd-ports@freebsd.org Fri Feb 22 16:11:26 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 8FC0614F1F70 for ; Fri, 22 Feb 2019 16:11:26 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay101.isp.belgacom.be (mailrelay101.isp.belgacom.be [195.238.20.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D3ADF738F8 for ; Fri, 22 Feb 2019 16:11:25 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CcAACqHnBc/99MQFdlDg4BAgQBCAQ?= =?us-ascii?q?BgVIHAQwBAYICVhFQASASJ4QHiBpfincBAYIMNQGJcI14gXsohFECg30jNAk?= =?us-ascii?q?NAQMBAQIBAQJtKEIBEAGEdgEBAQECASMzIwULCw4KAgIFIQICDyoeBhODIYF?= =?us-ascii?q?qDKwEgS+JH4EOgQuLVIF/g241iAuCVwKjWQmHPoNvhyclkw8tnh04gVZNMAi?= =?us-ascii?q?DJwmQGTw+AzABhSaKZAEB?= X-IPAS-Result: =?us-ascii?q?A2CcAACqHnBc/99MQFdlDg4BAgQBCAQBgVIHAQwBAYICV?= =?us-ascii?q?hFQASASJ4QHiBpfincBAYIMNQGJcI14gXsohFECg30jNAkNAQMBAQIBAQJtK?= =?us-ascii?q?EIBEAGEdgEBAQECASMzIwULCw4KAgIFIQICDyoeBhODIYFqDKwEgS+JH4EOg?= =?us-ascii?q?QuLVIF/g241iAuCVwKjWQmHPoNvhyclkw8tnh04gVZNMAiDJwmQGTw+AzABh?= =?us-ascii?q?SaKZAEB?= Received: from 223.76-64-87.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([87.64.76.223]) by relay.skynet.be with ESMTP; 22 Feb 2019 17:11:24 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id x1MGBKOc003736; Fri, 22 Feb 2019 17:11:21 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Fri, 22 Feb 2019 17:11:20 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Steve Kargl Cc: "Russell L. Carter" , Diane Bruce , FreeBSD Ports ML , Eugene Grosbein Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222171120.0b4913c4@kalimero.tijl.coosemans.org> In-Reply-To: <20190221182451.GA82216@troutmask.apl.washington.edu> References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <20190221182451.GA82216@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D3ADF738F8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; ASN(0.00)[asn:5432, ipnet:195.238.0.0/19, country:BE]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Fri, 22 Feb 2019 16:11:26 -0000 On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, T=C4=B3l Coosemans wrote: >> 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. =20 >=20 > libgfortran is gfortran's runtime library. libgcc.a is gcc's=20 > runtime library. The link orders are the same: libgfortran > then libgcc_s; libgcc then libgcc_s No, libgcc is the runtime library for the entire compiler collection not just the C compiler. The order of libgcc.a and libgcc_s.so can be changed with -static-libgcc and -shared-libgcc: For the C compiler: default: libgcc.a -Wl,--as-needed libgcc_s.so -Wl,--no-as-needed -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a For gfortran: default: libgcc_s.so libgcc.a (like -shared-libgcc) -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a What my patch does is change the gfortran default into the C compiler default. >> 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. =20 >=20 > Just add -static to FFLAGS. Yep, you're building static > libraries. >=20 >> 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. =20 >=20 > Wouldn't that be a bug in the program that loads both? Perhaps yes, but it's same as with missing -rpath. We don't want to have to fix those bugs and we don't want users be confronted with them. > 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. Yes, libgcc_s implements stack unwinding and exception handling and libgcc.a does not. The stack unwinding and exception handling code has to be shared so all code in a process uses the same implementation and accompanying data structures.