bug#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build

[Bhavin Gandhi <bhavin7392@gmail.com>]

On Wed, 8 Dec 2021 at 23:04, Eli Zaretskii <eliz@gnu.org> 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
> > …
>
> 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?

> > […]
> > $ 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='-DMAIL_USE_LOCKF -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection'
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection'
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules'
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules'