Thanks, you all. I'm glad to be involved with such a great community, and .. I have a *lot* to learn. :)
On Wed, Mar 25, 2015 at 12:07 PM, Jakob Eriksson <ja...@aurorasystems.eu> wrote: > Excellent work! > > On March 25, 2015 4:18:15 PM CET, Rick Hanson <cryptor...@gmail.com> > wrote: > >> Hello, list! >> >> I thought I should write a few words on some information I’ve gleaned >> trying to build picolisp on some of the BSDs. There are people on this list >> with more experience than I with both BSD and picolisp; so please comment >> upon what I have to say, and weigh in where you feel, or know, that it is >> necessary, for the benefit of everyone. This is a learning experience for >> me. I am not in a position to write authoritatively. I will try to >> accurately report my findings, but please especially point out where I am >> wrong or being misleading. (I would have done this unintentionally, of >> course.) >> >> *Bottom Line* >> >> Starting from the picolisp 3.1.9.13 source — the latest as of this past >> weekend (more about this below) — I was able to successfully build and >> unit-test pil32 on the following BSDs: FreeBSD 10.1, OpenBSD 5.6, and >> NetBSD 6.1.5. Also, I was able to successfully build and unit-test pil64 on >> FreeBSD 10.1. (AFAIK, only FreeBSD, among the three, has bootstrap support >> (with pil32) to build pil64, and I only looked at the bootstrapping option >> for building pil64.) >> >> The following sections just spell out some detail about the builds. A >> quick note before that: on each BSD box in question, I had to install >> gmake. This shouldn’t be a surprise — picolisp builds need GNU make, and >> the BSDs’ stock make is BSD, not GNU. >> >> *FreeBSD 10.1* >> >> I was aiming for a pil64 build in this machine, so I started with a >> 64-bit (amd64) FreeBSD 10.1 box. First, I had to build pil32 (for the >> bootstrap build). >> >> On a fresh FreeBSD 10 box you won’t have gcc, so you need to install >> that. I used pkg for that (i.e. I didn’t build gcc from ports). Its >> interface is installed in /usr/local/bin/gcc48, by the way. >> >> But, why install gcc? After all, clang (the stock compiler) is a >> “drop-in replacement for gcc“, right? Wrong. If you try to build pil32 >> with clang, you will be greeted with the following errors. >> >> apply.o.log:apply.c:15:40: error: fields must have a constant size: >> 'variable length array in structure' extension will never be supported >> apply.o.log:apply.c:67:43: error: fields must have a constant size: >> 'variable length array in structure' extension will never be supported >> flow.o.log:flow.c:91:37: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:159:40: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:299:34: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:663:37: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:698:34: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:736:37: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> flow.o.log:flow.c:786:37: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> main.o.log:main.c:720:34: error: fields must have a constant size: 'variable >> length array in structure' extension will never be supported >> >> Yes, that’s right folks, clang does not support dynamically sized arrays >> and never will (!) as unequivocally stated by their error message: “extension >> will never be supported“ (“never”? really?). (Take that picolispers! >> This reminds me of the taunting Frenchman in Monty Python’s Holy Grail: “No >> chance, English bedwetting types!”) >> >> But gcc does support this; so, back to gcc. The objects build fine with >> gcc, but then we run into a problem in the link step. >> >> gcc48 -o ../bin/picolisp -m32 -rdynamic main.o gc.o apply.o flow.o sym.o >> subr.o big.o io.o net.o tab.o -lm >> /usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when searching >> for -lm >> /usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for >> -lm >> /usr/local/bin/ld: cannot find -lm >> /usr/local/bin/ld: skipping incompatible >> /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/libgcc.a when >> searching for -lgcc >> /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when searching >> for -lgcc >> /usr/local/bin/ld: cannot find -lgcc >> /usr/local/bin/ld: skipping incompatible >> /usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/../../../libgcc_s.so >> when searching for -lgcc_s >> /usr/local/bin/ld: skipping incompatible //usr/lib/libgcc_s.so when >> searching for -lgcc_s >> /usr/local/bin/ld: cannot find -lgcc_s >> /usr/local/bin/ld: skipping incompatible /lib/libc.so.7 when searching for >> /lib/libc.so.7 >> /usr/local/bin/ld: cannot find /lib/libc.so.7 >> /usr/local/bin/ld: skipping incompatible /usr/lib/libc_nonshared.a when >> searching for /usr/lib/libc_nonshared.a >> /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a >> /usr/local/bin/ld: skipping incompatible /usr/lib/libssp_nonshared.a when >> searching for /usr/lib/libssp_nonshared.a >> /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a >> >> Oops. gcc cannot find the 32-bit libraries. But they do exist on the >> stock system. Rrrr. This gcc, from pkg, is not built for multilib >> support. I might be able to build gcc in ports with multilib support, >> but I had another thought: can clang do just the link step? After all, >> it’s the stock compiler and the stock system already has the 32-bit >> libraries there. And yes, clang indeed does the job of finding them for >> the link step. >> >> So, you’d only need to change a line in src/Makefile at the link step to >> call clang instead of gcc, and you should have a successful pil32 build >> on 64-bit FreeBSD 10. >> >> Now, this brings us to *a change introduced in picolisp last weekend*, >> which is that src/Makefile has been changed so that it works for FreeBSD >> 10 in the way described above “out of the box” with the new version, >> 3.1.9.13. It has also been slightly refactored so that it is >> backward-compatible as regards the other systems (e.g. Linux, Solaris), >> i.e. it will work *the same way as before* on these systems, namely that >> gcc is (stil l) the interface for both the object build and the link >> step. Please be aware of this change; however, it shouldn’t give you a >> problem. Alex has already tested the change on some Linuxen, and I’ve >> already tested it on all the BSDs mentioned here. >> >> After building pil32, building pil64 is very easy (and fast!). >> >> Also, please note that I did not try building pil32 on FreeBSD 10.1 i386
