[Openmcl-devel] cannot build ccl-1.11.5 from sources on a 32-bit Gentoo linux box

R. Matthew Emerson rme at acm.org
Sat Jul 7 02:14:10 PDT 2018 

https://github.com/Clozure/ccl/issues/126 is an issue about Gentoo (apparently a Gentoo project that seeks to improve security has a rule that programs mustn’t use absolute addressing).  I don’t know if that issue is related, but when I saw the linker warning about the text relocation, I thought of that issue.

There’s another 32-bit-only Linux problem that I ran into also, but in this case, the lisp crashes.  That’s issue https://github.com/Clozure/ccl/issues/85.




> On Jul 4, 2018, at 6:43 AM, Andrey G. Grozin <A.G.Grozin at inp.nsk.su> wrote:
> 
> It used to build fine. But after recent massive softwate upgrades, the build process hungs:
> 
> make -j3 -C lisp-kernel/linuxx8632 clean
> make: Entering directory '/var/tmp/portage/dev-lisp/clozurecl-1.11.5/work/ccl/lisp-kernel/linuxx8632'
> /bin/rm -f pmcl-kernel.o gc-common.o x86-gc.o bits.o  x86-exceptions.o x86-utils.o image.o thread_manager.o lisp-debug.o memory.o unix-calls.o x86-asmutils32.o  imports.o lispdcmd.o plprint.o plsym.o xlbt.o x86_print.o ../../lx86cl
> /bin/rm -f pad.o x86-spjump32.o x86-spentry32.o x86-subprims32.o
> make: Leaving directory '/var/tmp/portage/dev-lisp/clozurecl-1.11.5/work/ccl/lisp-kernel/linuxx8632'
> make -j3 -C lisp-kernel/linuxx8632 all CC=i686-pc-linux-gnu-gcc
> make: Entering directory '/var/tmp/portage/dev-lisp/clozurecl-1.11.5/work/ccl/lisp-kernel/linuxx8632'
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../pad.s | as  --32 -o pad.o
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../x86-spjump32.s | as  --32 -o x86-spjump32.o
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../x86-spentry32.s | as  --32 -o x86-spentry32.o
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../x86-subprims32.s | as  --32 -o x86-subprims32.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../pmcl-kernel.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o pmcl-kernel.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../gc-common.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o gc-common.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../x86-gc.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o x86-gc.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../bits.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o bits.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../x86-exceptions.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o x86-exceptions.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../x86-utils.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o x86-utils.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../image.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o image.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../thread_manager.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o thread_manager.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../lisp-debug.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o lisp-debug.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../memory.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o memory.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../unix-calls.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o unix-calls.o
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../x86-asmutils32.s | as  --32 -o x86-asmutils32.o
> m4 -DLINUX -DX86 -DX8632 -DHAVE_TLS -I../ ../imports.s | as  --32 -o imports.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../lispdcmd.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o lispdcmd.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../plprint.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o plprint.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../plsym.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o plsym.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../xlbt.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o xlbt.o
> i686-pc-linux-gnu-gcc -include ../platform-linuxx8632.h -c ../x86_print.c -DLINUX -D_REENTRANT -DX86 -DX8632 -D_GNU_SOURCE -DHAVE_TLS -DVC_REVISION="v1.11.5-dirty"  -g -O2 -Wno-format -m32 -o x86_print.o
> i686-pc-linux-gnu-gcc  -m32 -g  -Wl,--export-dynamic "-Wl,--hash-style=sysv" -o ../../lx86cl  pad.o x86-spjump32.o x86-spentry32.o x86-subprims32.o pmcl-kernel.o gc-common.o x86-gc.o bits.o x86-exceptions.o x86-utils.o image.o thread_manager.o lisp-debug.o memory.o unix-calls.o x86-asmutils32.o  imports.o lispdcmd.o plprint.o plsym.o xlbt.o x86_print.o -Wl,--no-as-needed -ldl -lm -lpthread -lrt
> /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: x86-spentry32.o: warning: relocation in read-only section `.text'
> /usr/lib/gcc/i686-pc-linux-gnu/7.3.0/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.
> make: Leaving directory '/var/tmp/portage/dev-lisp/clozurecl-1.11.5/work/ccl/lisp-kernel/linuxx8632'
> 
> After that point, lx86cl just runs forever, consuming 100% CPU:
> 
>  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
> 15887 portage   20   0 1917616  20048   4032 R  99.7   1.0   5:13.03 lx86cl
> 
> What can be the reason of this (presumably) infinite loop?
> 
> Andrey
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list