Re: Building picolisp on (some) BSDs
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
Building picolisp on (some) BSDs
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_sso 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
