bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)
Hi, On Tue, 01 Aug 2023 at 17:37, Adam Porter wrote: > I don't know enough about Guix to understand why using "guix install" > with the package transformation option caused the runtime problem with > gcc, but everything does seem to work with the updated definition. See Josselin’s explanations. :-) > So I guess this report can be closed. I am closing. And you could also do it just by appending -done in the bug email address; here 64999-d...@debbugs.gny.org. Cheers, simon
bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)
Hi Adam, Adam Porter writes: > OTOH, if anyone knows why the transformation option failed in that way, > it might be helpful to solve it if possible, so users could use the > option to install future releases without having to modify the package > definition. (AFAIK, I was able to do that for various Emacs 28 versions > without this problem, so I wonder if something's changed.) It's probably because emacs is missing the emacs-native-comp-driver-options.patch patch of emacs-next. Package transformations can't and won't replace the manual work of packaging new versions, so I think it is unreasonable to expect emacs 28's package definition to work with emacs 29. Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)
FYI, I hacked together a new package definition, updating the emacs-next one to build 29.1 from the release tarball, and after installing it, everything seems to work, including native compilation. I don't know enough about Guix to understand why using "guix install" with the package transformation option caused the runtime problem with gcc, but everything does seem to work with the updated definition. So I guess this report can be closed. OTOH, if anyone knows why the transformation option failed in that way, it might be helpful to solve it if possible, so users could use the option to install future releases without having to modify the package definition. (AFAIK, I was able to do that for various Emacs 28 versions without this problem, so I wonder if something's changed.) See also: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65000
