Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 166347
Summary: | clisp fails to build on power | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gérard Milmeister <gemi> | ||||||||
Component: | clisp | Assignee: | Gérard Milmeister <gemi> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 9 | CC: | bruno, extras-qa, rdieter, sds, tony, triage | ||||||||
Target Milestone: | --- | Keywords: | FutureFeature, Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | powerpc | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | bzcl34nup | ||||||||||
Fixed In Version: | Doc Type: | Enhancement | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2009-07-14 16:57:24 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 179260 | ||||||||||
Attachments: |
|
Description
Gérard Milmeister
2005-08-19 17:01:27 UTC
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. |