Bug 166347 - clisp fails to build on power
clisp fails to build on power
Product: Fedora
Classification: Fedora
Component: clisp (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks: F-ExcludeArch-ppc
  Show dependency treegraph
Reported: 2005-08-19 13:01 EDT by Gérard Milmeister
Modified: 2009-07-14 12:57 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 12:57:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Build log for clisp-2.35 on ppc (100.17 KB, text/plain)
2005-08-29 19:06 EDT, Gérard Milmeister
no flags Details
Output from normal build with debugging (191.74 KB, text/plain)
2006-12-29 14:50 EST, David Woodhouse
no flags Details
Output from -DNO_GENERATIONAL_GC build with debugging (186.98 KB, text/plain)
2006-12-29 14:52 EST, David Woodhouse
no flags Details

  None (edit)
Description Gérard Milmeister 2005-08-19 13:01:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Galeon/1.3.21

Description of problem:
CLisp build fails on the ppc build system. Since the src rpm builds fine on PowerPC system, the problem seems to be with the differences of Power5 (the build system) and PowerPC.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Sam Steingold 2005-08-29 16:22:59 EDT
for the record: clisp builds fine on the SF CF ppc-osx2
Darwin ppc-osx2.cf.sourceforge.net 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:
20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC  Power Macintosh powerpc

also, for the record, it would be nice to see a failed build log 
(prererably clisp 2.35)
Comment 2 Gérard Milmeister 2005-08-29 19:04:18 EDT
I thought it might be related to this:

It might indeed be useful to have a PowerPC as a buildserver in place of (or in
addition to a Power5).
Comment 3 Gérard Milmeister 2005-08-29 19:06:20 EDT
Created attachment 118232 [details]
Build log for clisp-2.35 on ppc
Comment 4 Sam Steingold 2005-08-30 06:25:17 EDT
the build log indicates a crash on first GC. very common on unusual architectures.
if someone with access to the hardware in question (power5) wants to investigate
further, the place to start is the file clisp/unix/PLATFORMS.
specifically, try
$ ./configure --with-debug --build build-g
[PS I suggest a change in "Summary" to replace "power" with "power5" for clarity]
Comment 5 David Woodhouse 2006-12-29 07:01:03 EST
I can poke at it but it's not clear I'd be much use. Better for someone with a
bit more clue to mail me a SSH public key and I'll give access to suitable
machines for testing.

If something fails on POWER5 but not earlier processors, it _could_ be Altivec,
but it could also be that you're trying to execute pages which are marked
non-executable, like the stack. Older processors didn't catch that, but newer
ones do.
Comment 6 Sam Steingold 2006-12-29 10:05:02 EST
(In reply to comment #5)
> I can poke at it but it's not clear I'd be much use.

please do - with the latest CLISP sources.
please take a look at the "porting" section in 
Comment 7 David Woodhouse 2006-12-29 14:48:15 EST
Adding -DNO_GENERATIONAL_GC to CFLAGS prevents the error shown in the build log
but it just segfaults a little later. This is on Mac G5 with 4KiB pages. It
isn't faulting due to executing non-executable pages -- it's something else; I'm
not sure what.

Building on G4 too, to make sure it's really OK there.
Comment 8 David Woodhouse 2006-12-29 14:50:27 EST
Created attachment 144556 [details]
Output from normal build with debugging

 ./configure --prefix=/usr --libdir=/usr/lib --fsstnd=redhat --with-dynamic-ffi
--with-module=berkeley-db --with-module=clx/new-clx --with-module=pcre
--with-module=postgresql --with-module=rawsock --with-module=wildcard
--with-module=zlib --with-module=bindings/glibc --with-readline --build build 
--with-debug 2>&1 | tee build-debug.out
Comment 9 David Woodhouse 2006-12-29 14:52:22 EST
Created attachment 144558 [details]
Output from -DNO_GENERATIONAL_GC build with debugging

CFLAGS=-DNO_GENERATIONAL_GC ./configure --prefix=/usr --libdir=/usr/lib
--fsstnd=redhat --with-dynamic-ffi --with-module=berkeley-db
--with-module=clx/new-clx --with-module=pcre --with-module=postgresql
--with-module=rawsock --with-module=wildcard --with-module=zlib
--with-module=bindings/glibc --with-readline --build build  --with-debug 2>&1 |
tee build-debug.out
Comment 10 David Woodhouse 2006-12-29 15:05:06 EST
Strange. When I run the failing command manually it dies as shown above. But
when I run 'make interpreted.mem' in the build directory, it runs the _same_
command, and it seems to work. Compare http://david.woodhou.se/typescript.manual
Comment 11 David Woodhouse 2006-12-29 18:45:34 EST
Very strange. With this patch to the specfile, which _ought_ to be a no-op, it

Index: clisp.spec
RCS file: /cvs/extras/rpms/clisp/FC-6/clisp.spec,v
retrieving revision 1.21
diff -u -p -r1.21 clisp.spec
--- clisp.spec  13 Oct 2006 10:54:48 -0000      1.21
+++ clisp.spec  29 Dec 2006 23:30:51 -0000
@@ -20,7 +20,7 @@ BuildRequires:  libXmu-devel
 BuildRequires:  libXrender-devel
 BuildRequires:  libXt-devel
 BuildRequires: imake
-ExcludeArch:   ppc ppc64
+#ExcludeArch:  ppc ppc64
@@ -59,6 +59,7 @@ Files necessary for linking CLISP.
 CFLAGS="" ./configure --prefix=%{_prefix} \
            --libdir=%{_libdir} \
            --fsstnd=redhat \
@@ -72,8 +73,13 @@ CFLAGS="" ./configure --prefix=%{_prefix
            --with-module=zlib \
            --with-module=bindings/glibc \
            --with-readline \
-           --build build
+           --config build
+   cd build
+    ./makemake --with-dynamic-ffi  --prefix=/usr --libdir=/usr/lib
--fsstnd=redhat --with-module=berkeley-db --with-module=clx/new-clx
--with-module=pcre --with-module=postgresql --with-module=rawsock
--with-module=wildcard --with-module=zlib --with-module=bindings/glibc
--with-readline --srcdir=../src   > Makefile
+    make config.lisp
+    make
+    make check
+cd ..
Comment 12 Sam Steingold 2007-01-01 13:13:51 EST
(In reply to comment #11)
> Very strange. With this patch to the specfile, which _ought_ to be a no-op, it
> builds.

there is a "ulimit" command in configure that makes the patch not quite a no-op.

Comment 13 David Woodhouse 2007-01-01 15:49:23 EST
Hm. But does that explain why it works from 'make interpreted.mem' but not when
cut-and-pasting the same command by hand, as shown in comment #10?
Comment 14 Sam Steingold 2007-01-01 17:40:25 EST
(In reply to comment #13)
> Hm. But does that explain why it works from 'make interpreted.mem' but not when
> cut-and-pasting the same command by hand, as shown in comment #10?

no, I am lost here too...
Comment 15 David Woodhouse 2007-01-01 17:49:42 EST
If you give me a SSH public key I'll give you an account on suitable machines,
so you can try to work out what's going on -- or at least give your blessing to
the version built with the above workaround?
Comment 16 Sam Steingold 2007-01-02 09:35:54 EST
(In reply to comment #15)
> If you give me a SSH public key I'll give you an account on suitable machines,
> so you can try to work out what's going on -- or at least give your blessing to
> the version built with the above workaround?

you have my blessing to distribute CLISP buit with your workaround.
here is my public key:
Comment 17 Sam Steingold 2007-01-02 13:58:23 EST
thanks for the power5 account.
the connection appears to be dead, but so far I figured out the following:
do NOT disable Generational GC.

./configure --build build-O
cd build-O

just works.
the reason for the problems we observe with --build APPEARS to be that
the default stack limit is 10240, while configure limits it to 8192.
I am unable to test the conjecture because the connection is dead.

Comment 18 Sam Steingold 2007-01-02 16:19:48 EST
indeed ulimit is at fault and configure/cd/make works just fine.
I will fix the top-level configure not to reduce ulimit.
Comment 19 David Woodhouse 2007-01-06 21:18:07 EST
Gérard, will you trigger a build with the above workaround, or should I?
Comment 20 Gérard Milmeister 2007-01-07 05:41:26 EST
Yes, please do, but can you summarize what the workaround does. I only loosely
followed the discussion.
Comment 21 David Woodhouse 2007-04-30 09:28:16 EDT
Hm, after a successful local build (on rawhide), it fails in mock. 


Trying again on FC6 -- I think the build system might be using the FC6 kernel,
with 64KiB pages.
Comment 22 David Woodhouse 2007-05-03 12:16:30 EDT
No, I have FC6 machines on which it builds, and rawhide machines on which it
doesn't. It builds fine on one rawhide machine and not on another, and both are
Mac G5s. Confused.
Comment 23 David Woodhouse 2007-05-04 03:30:03 EDT
The patch from CVS doesn't seem to work. Just using 2.41 and this does though:
sed -i "s|ulimit -s 8192|ulimit -s unlimited|" configure

So we have a PPC build of clisp in Fedora. Now we just need the ppc64 build... :)
Comment 24 Rex Dieter 2007-07-12 15:36:24 EDT
I see this has been closed, but I don't clisp in any ppc repo(s) yet.  Am I
missing something?
Comment 25 Rex Dieter 2007-07-20 10:05:27 EDT
For F-7, not ever pushed as update, nor has any rawhide build been requested
(yet).  Maybe it was built during F-7 freeze?

Regardless, it's not available in any repo, so... ???

Comment 26 Bug Zapper 2008-04-03 12:17:56 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 27 Bug Zapper 2008-05-13 22:01:29 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 28 Bug Zapper 2009-06-09 18:02:50 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 29 Bug Zapper 2009-07-14 12:57:24 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.