Hi Tomas, > I am trying to compile the latest picolisp 3.1.10 on 32 bit ARM. > > I remember I sent a patch fixing ARM compilation a while ago but that > wasn't accepted, because the aditional cases would make the Makefile > "ugly".
Really? When was that? Please excuse my bad memory .. ;) > (cd src ; sed -i s/-m32//g Makefile) I see. So the problem is the 32-bit flag. > but then I get another error which I don't remember seeing before: > > gcc -o ../lib/ext -shared -export-dynamic ext.o -lcrypt > /nix/store/gkg7ha29gwl5vci9khk1x86zhbc6ayc7-binutils-2.23.1/bin/ld: > ext.o: relocation R_ARM_MOVW_ABS_NC against `Nil' can not be used when > making a shared object; recomp\ile with -fPIC > ext.o: could not read symbols: Bad value > collect2: error: ld returned 1 exit status > Makefile:151: recipe for target '../lib/ext' failed > make: *** [../lib/ext] Error 1 > > So my questions: > > 1) is it ok to simply compile everything with -fPIC? E.g. fixing the > makefile by calling > > (cd src ; sed -i s/-m32/-fPIC/g Makefile) > > or the picolisp binary should not be compiled with -fPIC? I would say that this is not right. The PIC flag (position independent code) is - as I understand it - needed for the shared object libraries (lib/ext and lib/ht), but not for the base system. But, on the other hand, this is a matter of the system. On Mac OS, for example, position independent code seems to be always necessary. > 2) How do I run the picolisp test suite to verify, that the build is > successful? This is an easier question. It is, BTW, also noted in the test file "@lib/test.l" itself: ### Unit Tests ### # Local usage: # ./pil lib/test.l $(/bin/pwd) -bye + # Global usage: # pil @lib/test.l $(/bin/pwd) -bye + If something goes wrong, it stops in an error break. Otherwise it simply prints OK. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
