andy@syma.sussex.ac.uk (Andy Clews) (04/10/91)
I'm trying to build C News on a Sequent Symmetery S81, running DYNIX 3.0.17 (basically a BSD4.2 system). I ran through the conf/build script and answered all the questions to the best of my knowledge and belief. To the question "Does your system have an ANSI-C-conforming <string.h>?" I answered "no" - because my system only appears to have <strings.h>, in /usr/include. Build happily continued to conclusion, but when I came to run doit.bin (with -i to prevent immediate installation) it stopped when it failed to find a <string.h> include file. Can I get around this by changing all #include <string.h> to #include <strings.h> ? Is <string.h> simply a typo, and should it actually be <strings.h> ? Anything else I can do? I've RTFM pretty thoroughly - hope I've not missed anything. -- Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England JANET: andy@uk.ac.sussex.syma BITNET: andy%syma.sussex.ac.uk@uk.ac
andy@syma.sussex.ac.uk (Andy Clews) (04/11/91)
From article <4829@syma.sussex.ac.uk>, by andy@syma.sussex.ac.uk (Andy Clews): > I'm trying to build C News on a Sequent Symmetery S81, running DYNIX 3.0.17 > (basically a BSD4.2 system). > [...] > Build happily continued to conclusion, but when I came to run doit.bin (with > -i to prevent immediate installation) it stopped when it failed to find a > <string.h> include file. Further to this, I have now succeeded in getting "doit.bin" to work, without any special tricks. I re-ran "build", having decided to change a couple of the original settings. For reasons I cannot adequately explain, doit.bin -i worked for me next time around. I am almost certain I answered "no" to build's "...<string.h>..." question the first time around, but it looks as if it failed to pick up the built-in string.h functions. It certainly has picked them up now, so all is A-OK at this time. Andy -- Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England JANET: andy@uk.ac.sussex.syma BITNET: andy%syma.sussex.ac.uk@uk.ac