From owner-freebsd-ports@freebsd.org Thu Feb 21 22:19:05 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 B373E14F36B9 for ; Thu, 21 Feb 2019 22:19:05 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay105.isp.belgacom.be (mailrelay105.isp.belgacom.be [195.238.20.132]) (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 EAB386A008 for ; Thu, 21 Feb 2019 22:19:04 +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?A2DsAQAbI29c/99MQFdkHQEBBQEHBQG?= =?us-ascii?q?BUwYBCwEBggJWgQISJ4QHiHmKdQEBggw1AYlwjXiBe4R5AoN5IzYHDQEDAQE?= =?us-ascii?q?CAQECbShCARABhHcBBSMzIxALDgoCAgUhAgIPKh4GE4UXrFaBL4kigQ6BC4t?= =?us-ascii?q?UgX+EI4gKglcCo1MJklIlkwstnhgHKoFWTTAIgyeQXj4DMIUnimQBAQ?= X-IPAS-Result: =?us-ascii?q?A2DsAQAbI29c/99MQFdkHQEBBQEHBQGBUwYBCwEBggJWg?= =?us-ascii?q?QISJ4QHiHmKdQEBggw1AYlwjXiBe4R5AoN5IzYHDQEDAQECAQECbShCARABh?= =?us-ascii?q?HcBBSMzIxALDgoCAgUhAgIPKh4GE4UXrFaBL4kigQ6BC4tUgX+EI4gKglcCo?= =?us-ascii?q?1MJklIlkwstnhgHKoFWTTAIgyeQXj4DMIUnimQBAQ?= 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; 21 Feb 2019 23:18:55 +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 x1LMIovn095654; Thu, 21 Feb 2019 23:18:54 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 21 Feb 2019 23:18:50 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Diane Bruce Cc: "Russell L. Carter" , FreeBSD Ports ML , Eugene Grosbein Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190221231850.46dd5374@kalimero.tijl.coosemans.org> In-Reply-To: <20190221183040.GA42303@night.db.net> References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <20190221183040.GA42303@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: EAB386A008 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; ASN(0.00)[asn:5432, ipnet:195.238.0.0/19, country:BE] 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 22:19:06 -0000 On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, T=C4=B3l Coosemans wrote: >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: =20 >>> Except python doesn't have an rpath which is why this keeps coming >>> up over and over again. =20 >>=20 >> 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. =20 >=20 > 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. >=20 >> Maybe we should compile *all* ports with gcc rpaths without depending >> on gcc, just like we already compile everything with -fstack-protector >> in LDFLAGS. >>=20 >> 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 =20 >=20 > What is really happening is gfortran links with libgfortran (surprise=20 > surprise) and libgfortran has the requirement for @GCC_4.6.0 or later >=20 >> 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 > Something like this was tried already. I'll have to dig into > my old notes.=20 With my patch libgfortran only needs GCC_4.2.0 and works with base libgcc_s.