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

Reply via email to