milton@milton.acs.washington.edu (Stephen Milton) (02/06/90)
I keep running into the same error...'cannot find strings.h' It apparently did not come with my developmnent system, but a lot of programs seem to expect it as a standard library...Any help appreciated.. Steve Milton...milton@milton.u.washington.edu
goer@sophist.uucp (Richard Goerwitz) (02/07/90)
In <1762@milton.acs.washington.edu> Stephen Milton writes: >I keep running into the same error...'cannot find strings.h' It >apparently did not come with my developmnent system, but a lot of >programs seem to expect it as a standard library. Try including <string.h> instead of <strings.h>. Question: Should we Xenix people "ln string.h strings.h"? If this doesn't work, then just try to compile, and look for error messages that might tell you what the program expects to be linked in or included, then play egrep in /usr/include[/sys] to find the missing parts. -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer
daveh@marob.masa.com (Dave Hammond) (02/07/90)
<7482@tank.uchicago.edu> Sender: Reply-To: daveh@marob.masa.com (Dave Hammond) Followup-To: Distribution: Organization: ESCC, New York City Keywords: In article <7482@tank.uchicago.edu> goer@sophist.UUCP writes: >In <1762@milton.acs.washington.edu> Stephen Milton writes: >>I keep running into the same error...'cannot find strings.h' >[Can] we Xenix people "ln string.h strings.h"? ^^^^^^^^^^^^^^^^^^^^^ Someone did exactly this on the machines here, a while back. It breaks nothing, and eliminates one porting nuisance. -- Dave Hammond daveh@marob.masa.com uunet!masa.com!marob!daveh
ghost@robecdc.UUCP (William.A.Sneed) (02/08/90)
In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes: >I keep running into the same error...'cannot find strings.h' It >apparently did not come with my developmnent system, but a lot of >programs seem to expect it as a standard library...Any help appreciated.. > >Steve Milton...milton@milton.u.washington.edu Who what when where why how hunh!?! If you have SCO it was included If your program has #include "strings.h" that's your problem Should be <strings.h> to use the system's library ------------------------------------------------------------------------------ -William A. Sneed uucp: ...!pyrdc!robecdc!ghost -Robec Dist. voice: (703) 631-4800 -Manassas, Va fax: (703) 631-4806 ------------------------------------------------------------------------------ Brain fried -- Core dumped ------------------------------------------------------------------------------ The words you have just read are strictly my own and no one else's. They in no way should be construed as anything but my own personal opinion. Besides no one else would lay claim to them. :-) :-) :-) ------------------------------------------------------------------------------
chip@tct.uucp (Chip Salzenberg) (02/10/90)
According to ghost@robecdc.UUCP (William.A.Sneed): >According to milton@milton.acs.washington.edu (Stephen Milton): >>I keep running into the same error...'cannot find strings.h' It >>apparently did not come with my developmnent system, but a lot of >>programs seem to expect it as a standard library...Any help appreciated.. > >Who what when where why how hunh!?! > If you have SCO it was included > If your program has #include "strings.h" that's your problem > Should be <strings.h> to use the system's library Please note how poorly this person is adjusted. >------------------------------------------------------------------------------ >-William A. Sneed uucp: ...!pyrdc!robecdc!ghost >-Robec Dist. voice: (703) 631-4800 >-Manassas, Va fax: (703) 631-4806 >------------------------------------------------------------------------------ >Brain fried -- Core dumped >------------------------------------------------------------------------------ > The words you have just read are strictly my own and no one else's. > They in no way should be construed as anything but my own personal > opinion. Besides no one else would lay claim to them. :-) :-) :-) >------------------------------------------------------------------------------ This signature has been marked for deletion. -- Chip Salzenberg at ComDev/TCT <chip%tct@ateng.com>, <uunet!ateng!tct!chip> "The Usenet, in a very real sense, does not exist."
karl@ddsw1.MCS.COM (Karl Denninger) (02/10/90)
In article <8@robecdc.UUCP> ghost@robecdc.UUCP (William.A.Sneed) writes: >In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes: >>I keep running into the same error...'cannot find strings.h' It >>apparently did not come with my developmnent system, but a lot of >>programs seem to expect it as a standard library...Any help appreciated.. >> >>Steve Milton...milton@milton.u.washington.edu > >Who what when where why how hunh!?! > If you have SCO it was included > If your program has #include "strings.h" that's your problem No, that is not the problem. > Should be <strings.h> to use the system's library Actually either will work -- if the file is there. There is no difference between the delimiters. Try it sometime. CONVENTION is that you use " " as delimiters on local include files, and < > on system files, but the compiler will search in both places with either delimiter. The problem is that /usr/include/strings.h is not in the Xenix distribution; that file is called "string.h". Linking one to the other is an acceptable solution if you don't like hacking on source code. From the /etc/perms directory: soft:SOFT f644 bin/bin 1 ./usr/include/string.h D03 soft:DOSDEV f644 bin/bin 1 ./usr/include/dos/string.h D01 As you can see, there is no "strings.h" file! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
mike@antel.uucp (Michael Borza) (02/12/90)
In article <1990Feb9.185219.11046@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >In article <8@robecdc.UUCP> ghost@robecdc.UUCP (William.A.Sneed) writes: >>In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes: >>>I keep running into the same error...'cannot find strings.h' It >> If your program has #include "strings.h" that's your problem > >No, that is not the problem. > >> Should be <strings.h> to use the system's library > >Actually either will work -- if the file is there. > >There is no difference between the delimiters. Try it sometime. CONVENTION >is that you use " " as delimiters on local include files, and < > on system >files, but the compiler will search in both places with either delimiter. Well, actually, the delimiters " " and < > may work the same on your particular system, but that is not the correct behaviour in K&R C, and probably not in ANSI C either. Double qoute delimiters cause the preprocessor to prepend the current directory to the search path for include files. Angle bracket delimiters cause only the "standard" directories to be searched, usualy /usr/include on UNIX systems. This means that a file strings.h in the current directory will be found if a preprocessor directive #include "strings.h" is in a given source file. It will not be found if the directive #include <strings.h> is issued and strings.h does not exist in the system include path. I was surprised enough by your assertion to try it here, under ISC 386/ix using AT&T's PCC compiler. As expected, " " and < > *do not* behave the same and *do* exhibit their correct, documented, and expected behaviour. If file inclusion does not work this way on your system, your compiler is broken. >Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike
erc@khijol.UUCP (Ed Carp, aka Mr. Ed the talking horse...) (02/13/90)
In article <25CFA63A.156D@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes: >Someone did exactly this on the machines here, a while back. >It breaks nothing, and eliminates one porting nuisance. Be sure that you put #define index strchr #define rindex strrchr in your string.h file, or your linker may complain if you port BSD code to *NIX. -- Ed Carp N7EKG/5 (28.3-28.5) uunet!cs.utexas.edu!khijol!erc Austin, Texas (512) 832-5884 "Good tea. Nice house." - Worf Opinions expressed are mine. Copyright 1990 Edwin R. Carp. All Rights Reserved.
art@pilikia.uucp (Art Neilson) (02/13/90)
In article <8@robecdc.UUCP> ghost@robecdc.UUCP (William.A.Sneed) writes: >In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes: >>I keep running into the same error...'cannot find strings.h' It >>apparently did not come with my developmnent system, but a lot of >>programs seem to expect it as a standard library...Any help appreciated.. >> >>Steve Milton...milton@milton.u.washington.edu > >Who what when where why how hunh!?! > If you have SCO it was included > If your program has #include "strings.h" that's your problem > Should be <strings.h> to use the system's library This blatantly in error. System V *has no* strings.h, the file is called string.h. BSD systems call string.h strings.h. Please check your facts before whipping out responses like the above. Whenever I run across errors regarding include files I (1) check the makefile to ensure I have the right defines turned on (2) add preprocessor support for inclusions if step (1) is correct. A simple #ifdef is all it takes ... #ifdef USG # include <string.h> #else # include <strings.h> #endif -- Arthur W. Neilson III | ARPA: manapua!pilikia!root@trout.nosc.mil Bank of Hawaii Tech Support | UUCP: uunet!ucsd!nosc!manapua!pilikia!root
karl@ddsw1.MCS.COM (Karl Denninger) (02/15/90)
In article <1990Feb12.140349.10280@antel.uucp> mike@antel.uucp (Michael Borza) writes: >In article <1990Feb9.185219.11046@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >>In article <8@robecdc.UUCP> ghost@robecdc.UUCP (William.A.Sneed) writes: >>>In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes: >>>>I keep running into the same error...'cannot find strings.h' It >>> If your program has #include "strings.h" that's your problem >> >>No, that is not the problem. >> >>> Should be <strings.h> to use the system's library >> >>Actually either will work -- if the file is there. For system library files, this is a true statement. >>There is no difference between the delimiters. Try it sometime. CONVENTION >>is that you use " " as delimiters on local include files, and < > on system >>files, but the compiler will search in both places with either delimiter. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This part has proven to be false and worked here due to the way we tend to group ".h" files and specify their locations (by passing a "-I" switch) >Well, actually, the delimiters " " and < > may work the same on your >particular system, but that is not the correct behaviour in K&R C, >and probably not in ANSI C either. Double qoute delimiters cause the >preprocessor to prepend the current directory to the search path for >include files. Angle bracket delimiters cause only the "standard" >directories to be searched, usualy /usr/include on UNIX systems. Unless you have a "-I" directive on the compiler call, which we did (oops) :-) >This means that a file strings.h in the current directory will be found >if a preprocessor directive > #include "strings.h" >is in a given source file. It will not be found if the directive > #include <strings.h> >is issued and strings.h does not exist in the system include path. Ah, but #include "strings.h" WILL find the file in /usr/include as well as your current directory. >I was surprised enough by your assertion to try it here, under ISC >386/ix using AT&T's PCC compiler. As expected, " " and < > *do not* >behave the same and *do* exhibit their correct, documented, and expected >behaviour. If file inclusion does not work this way on your system, >your compiler is broken. No, my example was broken. I was half-right. The assertion about #include "file.h" looking in system library space still holds (and I just checked it again to make sure I wasn't full of it). Thus, in this particular quoted case, it wouldn't matter. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
dhk@teletech.UUCP (Don H Kemp) (02/15/90)
From article <1762@milton.acs.washington.edu>, by milton@milton.acs.washington.edu (Stephen Milton): > I keep running into the same error...'cannot find strings.h' It > Steve Milton...milton@milton.u.washington.edu Try using <string.h>. This usually works here (System V Release 3.1 on a 3B2 (I _know_ it's not Xenix, but...)). Don -- Don H Kemp "Always listen to experts. They'll B B & K Associates, Inc. tell you what can't be done, and Rutland, VT why. Then do it." uunet!uvm-gen!teletech!dhk Lazarus Long