From owner-freebsd-ports@freebsd.org Fri Feb 22 18:27:39 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 F3F3114F5F99 for ; Fri, 22 Feb 2019 18:27:38 +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 90CDA80DE7; Fri, 22 Feb 2019 18:27:38 +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 x1MIRV52079635 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 Feb 2019 10:27:31 -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 x1MIRUli079634; Fri, 22 Feb 2019 10:27:30 -0800 (PST) (envelope-from sgk) Date: Fri, 22 Feb 2019 10:27:30 -0800 From: Steve Kargl To: Konstantin Belousov Cc: =?utf-8?Q?T=C4=B3l?= Coosemans , FreeBSD Ports ML Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222182730.GA33829@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> <20190222140407.2145c11e@kalimero.tijl.coosemans.org> <20190222133917.GZ2420@kib.kiev.ua> <20190222170959.02047c69@kalimero.tijl.coosemans.org> <20190222164454.GA33338@troutmask.apl.washington.edu> <20190222170911.GA2420@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222170911.GA2420@kib.kiev.ua> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 90CDA80DE7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] 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 18:27:39 -0000 On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > > > > Because FreeBSD usurped the name of a well-known library from a > > well-known open source project. Users might expect that that > > well-known library has the same ABI and functionality of the > > library provided by the well-known project. > Nothing was usurped, you can lower your tone. > > Initially libgcc_s.so.1 was provided by gcc and the library was updated > during the regular gcc imports. When gcc changed the license, the > libgcc_s.so.1 become stalled due to the block on the import of the new > gcc versions. I know the history. When FreeBSD decided to move away from gcc, then it should move away. That includes either removing libgcc_s.so or renaming it. As it is now, FreeBSD libgcc_s.so does not provide the ABI in the official libgcc_s.so as distributed with any version of gcc newer than gcc=4.5.z. It clearly is causing problems. Yes, I know some oddball architectures cannot (or at least could not) be compiled with clang/llvm, so contrib/gcc remains in the tree. In these special cases, then libgcc_s.so can be installed as part of installing contrib/gcc. > Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder, > some parts with compiler-rt functions. The new functions added by gcc > were not imported because nobody who can do that knew about the problem. > Generic hand-waving is not the problem description. > > Now, that the list of missing symbols is collected and possible sources > for them are identified, at least some gaps can be filled. > > > > > If nothing in base needs /lib/libgcc_s, then let's remove it. > > If nothing in base needs it, let's rename name it to libfreebsd_s.so. > This cannot be done, because it breaks the base system ABI. In > particular, after that almost all compiled C++ apps will be broken, and > significant amount of threaded programs as well. Then the assertion that nothing in base needs libgcc_s.so is wrong? And, yes, if an application is currently using /lib/libgcc_s.so, then it would need to be recompiled. When it is recompiled, it can use libcompiler_rt or, if need be, it can use the libgcc_s.so provided by a gcc port. -- Steve