Here are my findings: (at home: Fedora-9 i386, gcl-cvs 20080908) - SELinux is disabled - using the bundled binutils instead of the system ones (configure --enable-locbfd --disable-statsysbfd) - building everything with -O2 (-O3 is normally hardwired) then GCL builds completely. This also works in a local mock rawhide build. However a scratch build using koji fails. I found that there is a difference in the memory layout between local (kernel 2.6.14) and koji (2.6.18) and GCL tries to do some funny things (such as generating its own ld script) which probably makes it fail ultimately. In particular it tries to detect some memory layout parameters such as stack ceiling (0xffffffff on koji, 0xbfffffff locally, why is this?) and "shared library/C stack ceiling to heap" (sic) (herefore it looks at the last address used in `ldd /usr/bin/awk`!!!). Apropos SELinux: When loading an image dump (made using unexec known from emacs) GCL tries to change protection using mprotect. It is possible to configure the garbage collector to omit this step. Image loading then proceeds, but loading compiled Lisp modules later fails again due to mprotect. There is probably no way to circumvent this without making far reaching modifications to GCL memory management itself. Therefore creating a security context for GCL is probably the only way to make GCL work smoothly in the mid-term (provided we can get non-selinux builds to work). This is as far as I have come currently, I hope that together we may work out solutions. Regards, Gérard -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
