On 28 Dec 1999, Niels M�ller wrote:
> "Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
>
> > I saw this too, and assumed it was a BSD make vs GNU make, switched to
> > GNU, and that solved the problem.
>
> There are a few dependencies of GNU-make specific features. I should
> fix the README to say that clearly. But I don't see how switching to
> GNU-make could possibly solve this particular problem.
Actually, I'm not sure it did. I got an error that looked exactly like
what was posted, to the best of my memory, but now that I've installed
scsh and I'm getting farther, but now I am seeing the exact error given.
My mistake.
> > I've never been able to get any of the lsh snapshots to work under
> > FreeBSD, but 0.1.20 is the first time that I had this many problems
> > building lsh (the last time I tried was 0.1.12-0.1.15, or so).
>
> Can you please send me precise bug reports for the problems you find?
> To make it easy for me to fix it, I'd like to know (i) symptoms (i.e
> compiler error messages, etc), (ii) what the problem is, and (iii) the
> right way to solve the problem on BSD. Of course, patches for the code
> *and* the autoconf-related files are also appreciated.
I'll help out as best I can, but aside from typing ./configure, my
autoconf skill is nill. As for patches to the source, I'm willing, I'm
just not sure about Big Brother's take on a US citizen helping an overseas
crypto project, even if the patches don't touch the actual crypto code.
And how would you like it? It's my lunch break, so I'm going through the
whole process again, capturing it with script, doing any editing in a
seperate xterm, but diffing the changes. gzipped, off the list?
> > socklen_t isn't defined on any of the 4 Unix I use at work, but the source
> > makes no attempt to work around this.
>
> greping for socklen_t, it seems it is used in one place, in daemon.c.
> Can you tell me what the appripriate type is on your system? size_t or
> a plain int or something else? It should be straight-forward to add a
> configure test for it.
According to the man pages for getsockopt, FreeBSD 3.3 and Solaris 2.6
expect *int (so the variable would be int) and Unixware 4.2MP/2.1.3
expects *size_t.
> > The 0.1.20 snapshot requires a scheme compiler, though configure doesn't
> > die if it doesn't find one. I haven't seen this before, so I believe
> > that earlier snapshots had spki.c.xT in the distribution. I did laugh the
> > first time I saw this, though:
> >
> > false -l /home/ejs/lsh-0.1.20/src/scm/false-compat.scm -e main -l \
> > /home/ejs/lsh-0.1.20/src/scm/compiler.scm \
> > -s /home/ejs/lsh-0.1.20/src/scm/gaba.scm <spki.c >spki.c.xT
>
> ;-) As for the fallback SCHEME=false, that's the best way I could find to
> let the configure script continue, and still fail reliably if some of
> the automatically generated files must be remade.
I've no complaints with the fallback :-) I just don't know why scsh was
required, since it is mentioned in the docs only for hacking the source.
> Anyway, all needed *.x files are supposed to be included with the
> dist. You should not need any scheme just to do a plain ./configure &&
> make. They depend on the corresponding .h and .c files, though.
The .x file was there, the .xT wasn't (the above line, with the false, is
what I was referring to). I think I just figured it out, when I modify
spki.c to allow for sys/time.h, it gets caught in the dependancies.
Confirmed, when I touch spki.c back to the original time, the compile goes
fine without needing scsh. O.K., didn't think of trying to fix
complie-time errors as hacking, but as far as the computer's concerned, it
is.
