From owner-freebsd-ports@freebsd.org Fri Feb 22 16:11:10 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 2D81114F1EF8 for ; Fri, 22 Feb 2019 16:11:10 +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 CB35473878 for ; Fri, 22 Feb 2019 16:11:09 +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?A2CbAADOHXBc/99MQFdlHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBAYFTBSpWYQEgEieMIV+KdQEBggw1AYh3eY14gXuEeQKDfSM?= =?us-ascii?q?0CQ0BAwEBAgEBAm0oQgEQAYR2AQEBAQIBOhwjBQsLDgoJJQ8SGB4GExuEYAM?= =?us-ascii?q?NDK0yiAINgRCBDoxfgX+BEYMSgleICwKJZoZpS5IMMwmLLYN2gzElkU2BQi2?= =?us-ascii?q?RHox/OIFWTTAIgyeDPwEHjRc+AzCFJ4pkAQE?= X-IPAS-Result: =?us-ascii?q?A2CbAADOHXBc/99MQFdlHAEBAQQBAQcEAQGBUQcBAQsBA?= =?us-ascii?q?YFTBSpWYQEgEieMIV+KdQEBggw1AYh3eY14gXuEeQKDfSM0CQ0BAwEBAgEBA?= =?us-ascii?q?m0oQgEQAYR2AQEBAQIBOhwjBQsLDgoJJQ8SGB4GExuEYAMNDK0yiAINgRCBD?= =?us-ascii?q?oxfgX+BEYMSgleICwKJZoZpS5IMMwmLLYN2gzElkU2BQi2RHox/OIFWTTAIg?= =?us-ascii?q?yeDPwEHjRc+AzCFJ4pkAQE?= 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:09:59 +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 x1MG9xOv003712; Fri, 22 Feb 2019 17:09:59 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Fri, 22 Feb 2019 17:09:59 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Konstantin Belousov Cc: FreeBSD Ports ML Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222170959.02047c69@kalimero.tijl.coosemans.org> In-Reply-To: <20190222133917.GZ2420@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CB35473878 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,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:10 -0000 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. 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? 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.