From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 02697139694 for ; Thu, 3 Aug 2017 07:24:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 114DDE0E1A; Thu, 3 Aug 2017 07:23:50 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B8D3EE0DA3 for ; Thu, 3 Aug 2017 07:23:49 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ddATr-0000Z0-SN for gentoo-dev@lists.gentoo.org; Thu, 03 Aug 2017 09:23:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review Date: Thu, 3 Aug 2017 07:23:32 +0000 (UTC) Message-ID: References: <1501689535.795.1.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: slrn/pre1.0.0-26 (Linux) X-Archives-Salt: bb72bc35-d7bc-4df3-b23c-3854d7d497ca X-Archives-Hash: 10f244b03aa2ff593d639e9280fa411f Michał Górny wrote: > > 'No mainstream' as you claim it doesn't mean it's fine to invent yet > another completely incompatible solution. As I understand, the compatibility with Debian might be increased (keeping /lib32), at the cost of slightly decreasing the compatibility with Red Hat (concerning 32bit emulation). So depending on the use case, it might as well be more compatible. >> in _all_ /lib* directories > > This is not true. You are right, I had made a stupid mistake. (I forgot that I still have the symlink lib->lib64 so that of course I should not have wondered why all ld-* existed in both libs...) > the linker uses /lib path independently of how multilib is done > on the system. I am not sure whether I understand what you mean. Do you mean that practically sys-libs/binutils or sys-libs/glibc have hardcoded /lib -> 32bit /lib64 -> 64bit (concerning ld-*) unless one patches it out? In this case you are right that there is an upstream to follow. In this case I wonder why Debian decided to patch out this upstream decision to support /lib32. > The 32-bit proprietary binaries use exactly /lib which is the main > reason for the switch. I thought the main reason for the switch is to avoid the merging of /lib and /lib64 which in bug 506276 led to problems for debugging. For this reason I am afraid that now merging /lib and /lib32 might again lead to a similar type of problems. I am aware that exactly the cited problem is now mitigated, because this time the merging does not happen over a symlink. But anyway, it seems unnatural when "curing" from a merge to decide to merge something else.