Open juhp opened 2 months ago
Thanks for the report.
Does something in the build process change the racket
executable after it's installed? Maybe an extra operation like strip
?
The symptom suggests that the boot file meant to be in the executable isn't being found, maybe because the relevant ELF section was removed. At the same time, it seems that racket
ran well enough at one point with its embedded boot files to get itself installed (but I might be guessing wrong about the install process).
Does something in the build process change the
racket
executable after it's installed? Maybe an extra operation likestrip
?
Of course we strip and I suspect more these days. :-) (I can try disabling stripping though I would be somewhat surprised if it helps. Now I just tried your upstream Linux installer and it also has stripped binaries.) I will try to look more at the Fedora build to find clues about how it might be affecting the runtime artifacts. I may be helpful if I attach excerpts of the buildlog to show what is going on, anyway: but here are links to a couple in full anyway:
Unfortunately the rpm .spec file is not directly visible there (it is in the .src.rpm files of course), but I can attach that too.
I also did a Rawhide (devel version) aarch64 build. I haven't actually tested on the just released Fedora 40 (which comes between these two), but I would assume it will fail in the same way.
(Note these scratch build logs will disappear after 2 weeks)
A more useful question from me would have been: is a .rackboot
section present in the executable that crashes? My memory is hazy on this point, but I think some strip
modes end up removing that section, which would explain the startup problem. (I should make Racket detect when a section that it expects is missing and report a more useful error in that case. On my list.)
A more useful question from me would have been: is a
.rackboot
section present in the executable that crashes? My memory is hazy on this point, but I think somestrip
modes end up removing that section, which would explain the startup problem.
I remembered you had found a solution in https://github.com/racket/racket/issues/3726#issuecomment-798734769:
The problem is that a step in
rpmbuild
strips the ".rackboot" ELF section from theracket
executable. After some digging and searching (it seems that Rust has the same kind of issue) it appears that adding%global _find_debuginfo_opts --keep-section .rackboot
to "racket.spec.txt" solves the problem.
This is the most relevant parts of the current .spec I am using:
%prep
%autosetup -p1
# Remove bundled libffi
rm -r src/bc/foreign/libffi
%build
cd src
%configure \
--enable-pthread \
--enable-shared \
--enable-libffi \
--disable-libs \
--enable-lt="%{_bindir}/libtool" \
--disable-strip
%make_build
%install
%make_install -C src
# Delete mred binaries and replace them with links.
rm %{buildroot}%{_bindir}/mred
rm %{buildroot}%{_bindir}/mred-text
ln -s gracket %{buildroot}%{_bindir}/mred
ln -s gracket-text %{buildroot}%{_bindir}/mred-text
# Fix the rpath error.
chrpath --delete %{buildroot}%{_bindir}/racket
chrpath --delete %{buildroot}%{_libdir}/racket/gracket
# Fix paths in the desktop files.
sed -i "s#%{buildroot}##g" %{buildroot}/%{_datadir}/applications/*.desktop
# Validate desktop files
desktop-file-validate %{buildroot}/%{_datadir}/applications/*.desktop
# Remove the executable bit on legacy template file
chmod -x %{buildroot}%{_libdir}/racket/starter-sh
# disable check-buildroot for
# (see https://github.com/racket/racket/issues/3878 discussion)
%undefine __arch_install_post
%ldconfig_scriptlets
See the above linked build.log's to see what the macros actually expand to and run.
Do you have any pointers to linux build scripts to compare?
The issue is specifically that the tool which strips the debug info from ELF files to form separate -debuginfo
subpackages needs to be instructed not to strip away the custom .rackboot
ELF section. So you should just need to add the line, somewhere early in the specfile:
%global _find_debuginfo_opts --keep-section .rackboot
There's a little more info on what happens by default here, under "Post-build ELF object processing" (the anchor within the page isn't working for me).
There are other things that maybe should be tweaked, but probably better to get a working package before worrying about them.
Thanks @LiberalArtist - that worked great!
I wonder if there are any build-time tests I should run or at least way to verify the executable works.
Well maybe even just running racket --help
or racket --version
would be enough, I can try,
though I dunno if racket can run from a staging directory, perhaps some envvar needed?
I would also be very grateful for any other suggestions on how to improve the fedora .spec file. Let me post a link anyway once I have pushed it.
Good news is Racket now builds on Fedora without any obvious problems - the bad news is it segfaults immediately at startup
What version of Racket are you using? 8.12
What program did you run? racket
What should have happened? UI should start
If you got an error message, please include it here.
Please include any other relevant details Happens for both Fedora Linux 39 and 40
What other information can I provide?