From: James Y K. <fo...@fu...> - 2006-04-30 03:46:10
|
I recently discovered that the core files saved with save-lisp-and- die :executable t don't survive an RPM build. The files that make it into the RPM are missing their appended core file. What happens, it seems, is that "strip" doesn't know to look for random data appended to the executable, and doesn't copy it over to the output file. And strip is helpfully magically invoked upon executables by the RPM build process. The way to work around the issue is to chmod -x the files you don't want stripped, and then chmod +x them back in a postinstall script. Yay RPM. It might be nice if the core was put in a proper ELF section rather than simply being appended, so that strip/etc won't destroy it. But I'm mainly just sending this note in case someone else runs into this problem, to spare them some agony. James |
From: Rex D. <rd...@ma...> - 2006-04-30 18:22:51
|
James Y Knight wrote: > I recently discovered that the core files saved with save-lisp-and-die > :executable t don't survive an RPM build. The files that make it into > the RPM are missing their appended core file. What happens, it seems, is > that "strip" doesn't know to look for random data appended to the > executable, and doesn't copy it over to the output file. And strip is > helpfully magically invoked upon executables by the RPM build process. > The way to work around the issue is to chmod -x the files you don't want > stripped, and then chmod +x them back in a postinstall script. Yay RPM. > > It might be nice if the core was put in a proper ELF section rather than > simply being appended, so that strip/etc won't destroy it. You could try some rpm-specific workarounds: %define debug_package %{nil} %define __os_install_post %{nil} -- Rex |
From: Craig L. <Cr...@sc...> - 2006-04-30 19:27:22
|
On Sun, 2006-04-30 at 13:33 -0500, Rex Dieter wrote: > James Y Knight wrote: > > I recently discovered that the core files saved with save-lisp-and-die > > :executable t don't survive an RPM build. The files that make it into > > the RPM are missing their appended core file. What happens, it seems, is > > that "strip" doesn't know to look for random data appended to the > > executable, and doesn't copy it over to the output file. And strip is > > helpfully magically invoked upon executables by the RPM build process. > > The way to work around the issue is to chmod -x the files you don't want > > stripped, and then chmod +x them back in a postinstall script. Yay RPM. > > > > It might be nice if the core was put in a proper ELF section rather than > > simply being appended, so that strip/etc won't destroy it. > > You could try some rpm-specific workarounds: > %define debug_package %{nil} > %define __os_install_post %{nil} I used the following line in the .spec file for a Lispworks based application that I packaged: # Turn off executable stripping %define __spec_install_post /usr/lib/rpm/brp-compress ||: I'm not sure what the difference is between my method and Rex's method, but here it is anyway. Craig |
From: Rex D. <rd...@ma...> - 2006-05-01 11:59:42
|
Craig Lanning wrote: > On Sun, 2006-04-30 at 13:33 -0500, Rex Dieter wrote: >>James Y Knight wrote: >>>It might be nice if the core was put in a proper ELF section rather than >>>simply being appended, so that strip/etc won't destroy it. >>You could try some rpm-specific workarounds: >>%define debug_package %{nil} >>%define __os_install_post %{nil} > I used the following line in the .spec file for a Lispworks based > application that I packaged: > # Turn off executable stripping > %define __spec_install_post /usr/lib/rpm/brp-compress ||: > > I'm not sure what the difference is between my method and Rex's method, > but here it is anyway. AFAICT, __spec_install_post calls several other items, including debug_package, __arch_install_post, and __os_install_post. It's __os_install_post that does that actual stripping (as well as calling brp-compress). -- Rex |