bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build
Date: Wed, 08 Dec 2021 22:11:33 +0200

> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Thu, 9 Dec 2021 00:49:36 +0530
> Cc: 52376@debbugs.gnu.org
> 
> On Wed, 8 Dec 2021 at 23:56, Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > No clean-up is done between the two builds.
> >
> > Maybe you should do the cleanup.
> 
> How can I do that? By extracting the source tar again?

That's one way; another is to say "make extraclean".

> > Also you didn't show the "make install" commands -- are they
> > installing into different places?  Where are the corresponding
> > emacs.pdmp files?
> 
> The way this is being done right now is:
> 
> After all three are built, make install is run from build-gtk directory
> only. And for other two, only relevant files are copied over to the
> required locations as:
> 
> /usr/bin/emacs => /etc/alternatives/emacs => /usr/bin/emacs-28.0.90
> (actual binary)
> /usr/bin/emacs-28.0.90.pdmp
> /usr/bin/emacs-lucid => /etc/alternatives/emacs-lucid =>
> /usr/bin/emacs-28.0.90-lucid
> /usr/bin/emacs-28.0.90-lucid.pdmp
> 
> The corresponding directories from native-lisp for each of them are
> copied over as well to /usr/lib64/emacs/28.0.90/native-lisp/
> 
> This means the *.el and *.elc files from GTK3 build are used by the
> other two.

But what about the *.eln files? are they also reused?  That cannot
work, I think.

Also, I think the games you play with the *.pdmp files is the reason
for the problem.  Emacs decides where to look for the *.eln files by
the place where it finds the .pdmp file, and you rename those and use
symlinks for them.  I'm not sure the startup code supports what you
expect it to support.  I suggest to step in a debugger through the
code in load_pdump, and see which of the *.pdmp files it finds in the
problematic case; my guess is that it finds the one in the build
directory, not in the installation directory.

> These are the steps which happen after building all three:
> %{buildroot}: the final destination from which the RPM package is
> created, it is a chroot.
> %{version}: 28.0.90 here
> %{native_lisp}: /usr/lib64/emacs/28.0.90/native-lisp
> 
> # Remove versioned file so that we end up with .1 suffix and only one DOC file
> rm build-{gtk,lucid,nox}/src/emacs-%{version}.*
> 
> cd build-gtk
> %make_install
> cd ..
> 
> # Let alternatives manage the symlink
> rm %{buildroot}%{_bindir}/emacs
> touch %{buildroot}%{_bindir}/emacs
> 
> # Remove emacs.pdmp from common (we copy it over in later steps)
> rm %{buildroot}%{emacs_libexecdir}/emacs.pdmp
> 
> # Install emacs.pdmp of the emacs with GTK+
> install -p -m 0644 build-gtk/src/emacs.pdmp
> %{buildroot}%{_bindir}/emacs-%{version}.pdmp
> 
> # Install the emacs with LUCID toolkit
> install -p -m 0755 build-lucid/src/emacs
> %{buildroot}%{_bindir}/emacs-%{version}-lucid
> install -p -m 0644 build-lucid/src/emacs.pdmp
> %{buildroot}%{_bindir}/emacs-%{version}-lucid.pdmp
> 
> # Install the emacs without X
> install -p -m 0755 build-nox/src/emacs
> %{buildroot}%{_bindir}/emacs-%{version}-nox
> install -p -m 0644 build-nox/src/emacs.pdmp
> %{buildroot}%{_bindir}/emacs-%{version}-nox.pdmp
> 
> lucid_comp_native_ver=$(ls -1 build-lucid/native-lisp)
> nox_comp_native_ver=$(ls -1 build-nox/native-lisp)
> cp -ar build-lucid/native-lisp/${lucid_comp_native_ver}
> %{buildroot}%{native_lisp}
> cp -ar build-nox/native-lisp/${nox_comp_native_ver} %{buildroot}%{native_lisp}

I see you copy the *.eln files for the Lucid and no-X build, but not
for the GTK3 build?

> > Did the final dump process show that it loads "native-compiled lisp"
> > files for all the preloaded files?
> 
> In the native-lisp/*/preloaded directory there are 124 files, and the
> following log has 113 lines which say (native compiled elisp). It is
> same for all the 3 builds. This is what you were referring to, right?

Yes.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]