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)

I thought it might be related to this:
https://www.redhat.com/archives/fedora-extras-list/2005-August/msg00931.html

It might indeed be useful to have a PowerPC as a buildserver in place of (or in
addition to a Power5).

Created attachment 118232 [details]
Build log for clisp-2.35 on ppc

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]

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.

(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 
clisp/unix/PLATFORMS

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.

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

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

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
with
http://david.woodhou.se/typescript.make

Very strange. With this patch to the specfile, which _ought_ to be a no-op, it
builds.

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
 
 
 %description
@@ -59,6 +59,7 @@ Files necessary for linking CLISP.
 
 
 %build
+#CFLAGS="-DNO_GENERATIONAL_GC"
 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 ..
 
 %install
 rm -rf $RPM_BUILD_ROOT

(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.

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?

(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...

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?

(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:
ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAwQN1e5X0stEYOPkpOLF92/4evc8KykT7YuY2O28FMQLBDmi/BC6S8YScLPg+XgIXSKuWZ6hUP53qMeGcLJIEP7/+6SXwCtlqtalXbIUzJaG/8Hmf3JyAq3U9kgqjujuF03KrCmaf4miXpSPpnNRrVqOtC/U+RS/GfkHspcwLp0s=
sds

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
make

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.

indeed ulimit is at fault and configure/cd/make works just fine.
I will fix the top-level configure not to reduce ulimit.

Gérard, will you trigger a build with the above workaround, or should I?

Yes, please do, but can you summarize what the workaround does. I only loosely
followed the discussion.

Hm, after a successful local build (on rawhide), it fails in mock. 

http://buildsys.fedoraproject.org/logs/fedora-development-extras/32747-clisp-2.41-4.fc7/

Trying again on FC6 -- I think the build system might be using the FC6 kernel,
with 64KiB pages.

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.

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... :)

I see this has been closed, but I don't clisp in any ppc repo(s) yet.  Am I
missing something?

http://koji.fedoraproject.org/koji/buildinfo?buildID=6160
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... ???

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.