From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: Path for system-wide .eln files Date: Tue, 1 Sep 2020 10:46:24 +0200 Message-ID: <20200901084624.GD4108@tuxteam.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q9KOos5vDmpwPx9o" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40409"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 01 10:47:13 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kD1wd-000ANX-Tb for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 10:47:11 +0200 Original-Received: from localhost ([::1]:45116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kD1wc-00069r-Vp for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 04:47:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD1w7-0005ks-7e for emacs-devel@gnu.org; Tue, 01 Sep 2020 04:46:39 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:59391) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1kD1w5-0002Nb-24 for emacs-devel@gnu.org; Tue, 01 Sep 2020 04:46:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:Date; bh=oKzTKqIhU0ZdY4Id2jD35bWUgSrV8MzQbzH5Js1ZFuA=; b=nAbXYkVla+0cgLpKgT/Jcp4Tbg+9qo5BXIzZFBrdOynlJrQ5/L4DxMxpEseCPeLX8xz4EwUufAKjFqvVvTcArHPmWWzTZcj1DFcb0GtPH1CjgWjEBq6dJ52RrU5J5loInMnbxqF/h7MHmfcOMf+AJmxoFQQ6pxLmdF6yuxaRrxNFiPal3MzvV81OwiKT46bFMVyDveq4w6z43Wjk1MryIcysoWfCG/MXTj6up/+HALF0kzhd4pvXw4wQPUB3gesO4U5yInaQLu59WIN7JSgth5CMJwNc43ue8Ut03RW155qPgya7TBFWanyY5BalbNJUm31zYsKWvvQeXagGFy9K7g==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1kD1vs-0001Lp-LX for emacs-devel@gnu.org; Tue, 01 Sep 2020 10:46:24 +0200 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/01 04:18:10 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254469 Archived-At: --q9KOos5vDmpwPx9o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 01, 2020 at 09:16:48AM +0200, Ulrich Mueller wrote: > >>>>> On Tue, 01 Sep 2020, Yuri Khan wrote: >=20 > >> > AFAIU `/usr/libexec` would be for binaries in general, infact we sto= re > >> > there the pdumper img. Okay for `/usr/lib`. > >>=20 > >> It should be ${libdir} I think? That is, "lib64" on 64-bit systems. >=20 > > I am on a 64-bit system and my /usr/lib64 is empty except for a single > > ld-linux-x86-64.so.2 symlink. On the other hand, /usr/lib32 contains a > > number of shared objects belonging to the libc6-i386 package. This > > tells me maybe native bitness belongs in /usr/lib. >=20 > I should have been more precise. It is in fact distro specific, so there > may be 64-bit systems where the native libs are installed in /usr/lib > (and 32-bit libs would go to /usr/lib32), while others install the > native libs in /usr/lib64. Yes. Those are the ad-hoc "solutions" you find "in the wild". And then there is Debian multiarch [1], which is the "right" solution (roughly: /lib and /usr/lib contain the "native" stuff, for backward-compatibility; "foreign" stuff lives in {/lib,/usr/lib}/, e.g. /usr/lib/i386-linux-gnu. [2] After all, there's no reason not to want to have Arm binaries in an x86_64 machine (there's qemu, after all). > So the right thing to do is to use configure's ${libdir}. Exactly. Looking at one's distro and generalizing is going to bite someone. And then they'll be angry at us :) So use the configury, and fix that should it be broken. Cheers [1] https://wiki.debian.org/Multiarch/TheCaseForMultiarch [2] I said roughly. It's not (alas!) the well-known GNU triplet, but something similar, for Reasons [3] [3] https://wiki.debian.org/Multiarch/Tuples - t --q9KOos5vDmpwPx9o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAl9OCmAACgkQBcgs9XrR2kbDzACfZ/iw54U4HRc6sJYvTUh1l8mg 6vcAn0IGNDndktCDxhnFi6RjJXCfPh4i =YloU -----END PGP SIGNATURE----- --q9KOos5vDmpwPx9o--