Red Hat Bugzilla – Bug 427250
maxima --enable-gcl busted (x86_64)
Last modified: 2009-01-20 09:37:45 EST
Atm, maxima --enable-gcl builds are busted. ./configure fails with
configure: error: unable to run gcl executable "gcl".
Oddly, my own local mock builds are fine. ??
failed build: http://koji.fedoraproject.org/koji/buildinfo?buildID=29572
fwiw, only x86_64 is failing, i386, ppc seem fine.
nevermind about the ppc comment (no gcl there yet, per bug #167952) :)
I cannot test myself on x86_64. The last build seemed to be ok, but
the build.log is no longer available, so I cannot check it.
gcl is really a pain on anything other than i386. I do not know
what other distros do. The Debian diff is a full 13MB!
ok, I'll just disable x86_64/gcl for now (and reassign to maxima), until a
better solution presents itself.
gcl-pers.patch is trying to set the personality on /proc/self/exe. Looking at
the equivalent patch for sbcl, there, Rex Dieter added this:
The relevant lines:
+ /* if /proc isn't available (like in chroot builds, like
+ * try using execvp with argv instead */
+ execvp(argv, argv);
Could this be the origin of the breakage (maybe also the one on ppc)?
Especially as the comments below the use of /proc/self/exe in gcl-pers.patch
+ /* Either changing the personality or execve() failed. Either
+ * way we might as well continue, and hope that the random
+ * memory maps are ok this time around.
This looks very much like an explanation for non-reproducible errors to me.
This build failure of gcl itself also looks very much like this is the issue:
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
* Sun Jan 18 2009 Rex Dieter <firstname.lastname@example.org> - 5.17.1-3
- reenable gcl on i386 (#451801), x86_64 (#427250), ppc (#167952)