khc@eecea.eece.ksu.edu (Ken Carpenter) (06/01/90)
khc@eecea.eece.ksu.edu (Ken Carpenter) writes: >In trying to compile a large piece of code that was originally >written for bsd4.3, I finally got the compiling done without error >by using -I/usr/include/bsd43 on the cc command line. >Now when linking I have -lbsd specified, but still get an error >message about three unfound symbols: setsigmask, sigvec, and ftime. >Does anyone know what library these are found in? Thanks for the replies to the above. The two suggested solutions were to use the switch "-systype bsd43" with the sysV cc, and to use the /bsd43/bin/cc as the compiler. Here is what happened in my case: 1. makefiles contained CC = /bin/cc originally - thus the fact that /bsd43/bin was first in my path did not matter. 2. When the BSD code was made with CC = /bin/cc and "-systype bsd43" was added to CFLAGS the make was without error. However, the executable dumped core on invocation. 3. When the BSD code was made with CC = /bsd43/bin/cc and no addition to CFLAGS, the make was without error, and the code ran almost the same as on a Sun 4/60. (The difference may be a machine dependent bug, not something in the compiling or linking.) Conclusion: porting BSD4.3 code, use /bsd43/bin/cc explicitly when compiling and linking, and make no other changes. Kenneth H. Carpenter | 913-532-5600 | khc@eecea.eece.ksu.edu Electrical & Computer Engineering Department | KHC@ksuvm.bitnet Kansas State University - Durland Hall | rutgers!ksuvax1!eecea!khc Manhattan, KS 66506 | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!khc
jay@mips.COM (Jay McCauley) (06/01/90)
In article <1990Jun1.132149.29655@maverick.ksu.ksu.edu> khc@eecea.eece.ksu.edu (Ken Carpenter) writes: > >khc@eecea.eece.ksu.edu (Ken Carpenter) writes: > >>In trying to compile a large piece of code that was originally >>written for bsd4.3, I finally got the compiling done without error >>by using -I/usr/include/bsd43 on the cc command line. >>Now when linking I have -lbsd specified, but still get an error >>message about three unfound symbols: setsigmask, sigvec, and ftime. >>Does anyone know what library these are found in? > >Thanks for the replies to the above. The two suggested solutions were >to use the switch "-systype bsd43" with the sysV cc, and to use the >/bsd43/bin/cc as the compiler. Here is what happened in my case: >1. makefiles contained CC = /bin/cc originally - thus the fact > that /bsd43/bin was first in my path did not matter. > >2. When the BSD code was made with CC = /bin/cc and > "-systype bsd43" was added to CFLAGS > the make was without error. However, the executable dumped core > on invocation. > >3. When the BSD code was made with CC = /bsd43/bin/cc and > no addition to CFLAGS, the make was without error, and the code > ran almost the same as on a Sun 4/60. (The difference may be a > machine dependent bug, not something in the compiling or linking.) > >Conclusion: porting BSD4.3 code, use /bsd43/bin/cc explicitly when >compiling and linking, and make no other changes. Cases 2 and 3 are equivalent. All /bsd43/bin/cc does is set -systype bsd43 if you have not already set it to something. (I've got it's source in another window... yup, that's all it does.) I'd look to other makefile subtlties for the failure in case 2. One possible one that bites us occasionally when working on a single program being compiled twice with two different -systypes (we do tar this way), is that you get a stale .o compiled for the other systype, and when everything is bound into an executable, it typically core dumps due to library and include file mismatches. The fix is to do "make clobber" or your favorite target that erases all the .o's and try it again. In our development environment for RISC/os, we use only method 2. That is, our makefiles explicitly specify the -systype if it is not the system default (sysv). If there are other problems that represent bugs, we'd like to hear about them via the usual channels. We consider compatibility problems with std baselines "worthy of comment" and would like to have as few of 'em as possible. > > >Kenneth H. Carpenter | 913-532-5600 | khc@eecea.eece.ksu.edu >Electrical & Computer Engineering Department | KHC@ksuvm.bitnet >Kansas State University - Durland Hall | rutgers!ksuvax1!eecea!khc >Manhattan, KS 66506 | {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!khc -- Jay McCauley MIPS Computer Systems, 928 E. Arques, Sunnyvale, CA 94086 (408)524-8211 {decwrl,pyramid,ames}!mips!jay jay@mips.com
steven@pacific.csl.uiuc.edu (Steven Parkes) (06/02/90)
|> One possible one that bites us |> occasionally when working on a single program being compiled twice with |> two different -systypes (we do tar this way), is that you get a stale |> .o compiled for the other systype, and when everything is bound into |> an executable, it typically core dumps due to library and include |> file mismatches. Is there anyway to tell what systype a .o was compiled for? (i.e. via nm, etc) |> Jay McCauley Same one that used to work at Zilog?
jay@mips.COM (Jay McCauley) (06/04/90)
In article <1990Jun1.200430.14118@ux1.cso.uiuc.edu> steven@pacific.csl.uiuc.edu writes: > >|> One possible one that bites us >|> occasionally when working on a single program being compiled twice with >|> two different -systypes (we do tar this way), is that you get a stale >|> .o compiled for the other systype, and when everything is bound into >|> an executable, it typically core dumps due to library and include >|> file mismatches. > >Is there anyway to tell what systype a .o was compiled for? (i.e. via nm, etc) None that I know of. Sounds like an RFE, I'll ask the compiler folks about it. Future work in support of dynamic linking does fairly extensive checking of this sort of thing, although I am not sure about the -systype specifically. I think that check is implicit in matching up to the right shared lib. > >|> Jay McCauley > >Same one that used to work at Zilog? Jay, glancing furtively, says, "Yes, but I've changed." (how's that for a reply that covers all possible questions?) That was A LONG time ago by Silly Con valley standards. Jay -- Jay McCauley MIPS Computer Systems, 928 E. Arques, Sunnyvale, CA 94086 (408)524-8211 {decwrl,pyramid,ames}!mips!jay jay@mips.com