From owner-freebsd-ports@freebsd.org Fri Feb 22 17:09:20 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 6BC3914F3D14 for ; Fri, 22 Feb 2019 17:09:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63D2075F4F; Fri, 22 Feb 2019 17:09:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1MH9B2Q084451 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Feb 2019 19:09:14 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1MH9B2Q084451 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1MH9B8x084450; Fri, 22 Feb 2019 19:09:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Feb 2019 19:09:11 +0200 From: Konstantin Belousov To: Steve Kargl Cc: =?utf-8?Q?T=C4=B3l?= Coosemans , FreeBSD Ports ML Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222170911.GA2420@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190222164454.GA33338@troutmask.apl.washington.edu> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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 17:09:20 -0000 On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: > > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov > > wrote: > > > Yes, we absolutely must avoid situation where two similar libraries > > > (i.e. providing some subset of symbols from other) are linked into the > > > same executing process. > > > > > > I think your patches would be a definitive improvement, esp. the part > > > which makes libgfortran linking only as needed. > > > > > > For the other part, which makes the ports dso a priority over the base > > > dso, I would exercise some more causion. For ports we know only about > > > libgcc_s.so.1 which has the same name in base and in ports, other > > > libraries in base should have libprivate suffix to not conflict, right ? > > > What about openssl libraries ? > > > > As long as libraries have a different name the search order in the > > ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x > > don't conflict but neither do libfoo.so.x and libfoo.so.y. Some > > libraries in base have the libprivate prefix and they are not meant to > > be used by ports at all. The openssl libraries in base have a different > > version suffix than security/openssl* and are allowed to be used by > > ports. > > > > > I think such setup makes it easier for user to accidentaly break the system. > > > She could install something manually (not from ports), or copy some file > > > into /usr/local/lib, which conflicts with base and cause troubles. > > > > Or they could copy something in /lib or /usr/lib and break their system. > > > > The idea behind the ldconfig patch is that the runtime search order > > should be as close as possible to a typical compile time order. > > Typically compilers and linkers search /usr/local before /usr, so > > ldconfig should search /usr/local before /usr. Anyone that wants a > > different order needs to provide a good explanation for that and I don't > > think protecting users from shooting themselves in the foot is a good > > enough reason. > > > > Similarly, I think our default PATH is also backwards. Major Linux > > distros and MacOS all put /usr/local/bin before /usr/bin. > > > > # User can override sysadmin who can override OS: > > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > > > > > Do you agree that the ultimate and proper solution is to add missed symbols > > > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started > > > to show some work which might finally solve that. > > > (But about as-needed for libgfortran see above). > > > > Not really no: > > > > 1) GCC can add new symbols or new versions of them with every release > > which means the problem can reappear with every new GCC release and GCC > > releases aren't aligned with FreeBSD releases. > > GCC developers do add new symbols. Not sure what you mean by > new versions. The ABI is stable. If they change the ABI, then > they would bump the major number to 2. They add new symbols and provide new symbol versions where these symbols are assigned. > > > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler > > runtime. LLVM doesn't seem to need these symbols, nothing in base needs > > these symbols so why should we implement these third party compiler > > runtime helper functions? > > 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. 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. > > > 3) With my gfortran patch you don't need to implement anything. It's an > > apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. > > Your patching a gfortran spec file. Don't you need to worry > about the spec file changing, which may invalidate your patch? > > -- > Steve