From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bhavin Gandhi Newsgroups: gmane.emacs.bugs Subject: bug#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build Date: Wed, 8 Dec 2021 23:35:40 +0530 Message-ID: References: <83a6hbvw5d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35173"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52376@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 08 19:07:17 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mv1LY-0008sx-Fy for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 19:07:16 +0100 Original-Received: from localhost ([::1]:46306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv1LW-0001G3-QJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 13:07:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv1LL-0001FW-4i for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 13:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57999) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mv1LK-0006Mq-Tj for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 13:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mv1LK-00007i-GB for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 13:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bhavin Gandhi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52376 X-GNU-PR-Package: emacs Original-Received: via spool by 52376-submit@debbugs.gnu.org id=B52376.1638986788431 (code B ref 52376); Wed, 08 Dec 2021 18:07:02 +0000 Original-Received: (at 52376) by debbugs.gnu.org; 8 Dec 2021 18:06:28 +0000 Original-Received: from localhost ([127.0.0.1]:41312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv1Km-00006s-7q for submit@debbugs.gnu.org; Wed, 08 Dec 2021 13:06:28 -0500 Original-Received: from mail-yb1-f179.google.com ([209.85.219.179]:44940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv1Kh-00006d-CZ for 52376@debbugs.gnu.org; Wed, 08 Dec 2021 13:06:27 -0500 Original-Received: by mail-yb1-f179.google.com with SMTP id q74so7811145ybq.11 for <52376@debbugs.gnu.org>; Wed, 08 Dec 2021 10:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LlybuxT/iZzv6BBmZ4B4dvdkEI2IJSC9PmV9Xr3YHDg=; b=YMTrw9guvIbrWcuD2nl7SM5wovdi+p2tgoU8bctzsFtezbMpWmHQKLOx4eoAcTkP+k ndMWk/tH8wLb0LEBpzT9ls4n3CnQcab4AruuYPD/D+ipHzYL/gz6xEcSy5GNqJXvvpjJ iJJBqNvks0njExL/qlIoFx8Bu3IwUPCpe4yAwtnIm8VCOITsUyfAe6gcHVgETJfFiziC uctSs8q7vUx01le+z1JK1JxGlUORVcjKi1ET7CjtiE9M1y6iRjZuWqUtesw1oX4Qd1WD huYsrf5eEw3P7cEah34QBXP4/DZkuDpwcvx8ke68qAujcT13KM34+9baRLnK4xm5cQjo Kr9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LlybuxT/iZzv6BBmZ4B4dvdkEI2IJSC9PmV9Xr3YHDg=; b=Uc4U19Ctvzln+PaSp07FYvEfgCLLrcKrCH1yb+5E/DF4xVLMw017kNRuslFSi04TnQ 6OY/3CsxHUETWDCvdXS4q8Xp4qkNc+mSxIgGqq76259o5iXine1XC4yZJAEZXPcx/i8y ENPqfY3mbb7tnoO/EszqtSPUkiE6rSzCNV2LdY41DFEsCP5tCSYtH2cnFgxBxwEA8x3F UPx2rW+rVNjASLpXJDOifEOKBNUyJ3zzXiQ0uDvcUvaKDB5maF3PdOYHkVkGJjniFVgg zFNDuTQVEtZ3+LGIOKaNQeVKYBeADawJ1cYTB/gG7COr3GKMzCrRDw4pSi4HK8S/vtDL QOUA== X-Gm-Message-State: AOAM533mFzCKbg2QJQ31lWbzhT+lizbSa+zwIql6cI40hNTFbhRznzBP Py+NujyhPJ957Mh7vIOfsYCQ2lnBTyqpZZa8PVMxaxpg4kI= X-Google-Smtp-Source: ABdhPJwXzhZUJQSGQRQLa9MZUvOvksehBQr7Xore6gjcpcaWdgu+6z1hJHwpFVG7+vdfqTTxw9mmdLO9VCCY48A1GGw= X-Received: by 2002:a25:3fc3:: with SMTP id m186mr306932yba.562.1638986777608; Wed, 08 Dec 2021 10:06:17 -0800 (PST) In-Reply-To: <83a6hbvw5d.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221936 Archived-At: On Wed, 8 Dec 2021 at 23:04, Eli Zaretskii wrote: > Please describe in more detail how you build the 3 versions. Are you > using the same source tree, but different build directories, for > example? Do you clean up the tree between different builds? Same source tree is used like this (removing templating used by RPM spec file): mkdir build-gtk && cd build-gtk ln -s ../configure . ./configure[1] make bootstrap make cd .. mkdir build-lucid && cd build-lucid ./configure [flags] make bootstrap make cd .. mkdir build-nox && cd build-nox ln -s ../configure . ./configure [flags] # there is no bootstrap here, not sure why that's the case. make No clean-up is done between the two builds. > This is normal if you start Emacs from the build tree. is that what > you did? I'm starting it from home and not from the build tree. The container which build the binaries (and the package), and the one which is running it are different. > > $ ls -ll /usr/lib64/emacs/28.0.90/native-lisp/28.0.90-619a407c/ > > total 3080 > > -rw-r--r--. 1 root root 81216 Dec 8 15:14 autoload-f3599901-fca77eea.= eln > > =E2=80=A6 > > Was this directory produced by "make install" from the same build > that built the GTK3 version? The *.eln files are specific to the > binary with which they were produced, so the fact that you have the > *.eln files there doesn't yet mean that a specific Emacs binary will > accept them as matching the binary. Yes, these files are produced by the same build which created the GTK3 version. The comp-native-version-dir variable's value matches the above one. Is there any other way to verify that the *.eln files are the correct = ones? > > [=E2=80=A6] > > $ make -j8 bootstrap > > $ make -j8 > > $ sudo make -j8 install > > How is this different from the commands you used to produce the build > which didn't find the *.eln files? One difference is having a different build directory (like build-gtk), and the RPM build process adds a bunch of CFLAGS, and few more variables. [1] Here are all the extra flags added when building via RPM packaging script (spec file), but these are the same for all 3 builds in this case. + CFLAGS=3D'-DMAIL_USE_LOCKF -O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=3Dgeneric -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' + export CFLAGS + CXXFLAGS=3D'-O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=3Dgeneric -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' + export CXXFLAGS + FFLAGS=3D'-O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=3Dgeneric -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules' + export FFLAGS + FCFLAGS=3D'-O2 -flto=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=3Dgeneric -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules'