asg@sage.cc.purdue.edu (The Grand Master) (06/26/91)
OK I am getting there. As you all know by know Trying to compile 1.6.16 on an IBM PS/2 286 Problems still: I got kernel to compile by replacing sigaddset, sigismember, sigdelset, and sigemptyset with the corresponding lines from the 1.5.10 kernel (this occurs in system.c). I could not do the same however in mm, becauase of the number of occurences (signal.c, exec.c, main.c, break.c) and the complexity of some of those. The old versions of these files use certain variables in the location where the new versions use sig*, but said variables are not present anywhere in the new version. HELP!! Why are sigaddset, sigdelset, sigemptyset, and sigismember undefined!?!?!?? If you wanna see where they are they are in /usr/include/signal.h There are defined like: _PROTOTYPE (sigdelset, (sigset_t *_set) ); /* or something like that */ A friend of mine said that the a procedure defined with the _PROTOTYPE call will be left unset if using a K&R compiler (That is what cc is right?) So how can I have these defined???? Is there anyone out there who got 1.6.16 to compile using the plain 1.5.10 compiler?? Ugh - this is really frustrating. Three weeks I have been trying to compile 1.6.16 If I do not get it straight soon, I am going to delete 1.6.16 and just live with 1.5.10. When is 2.0 due out??? Bruce
cad@csun5.uta.edu (cad dir user) (06/26/91)
Anyone can tell me where can I get the 1.16.16 ? or The newest version ? -botaque
SRONCH%HLERUL2.BITNET@vm.biu.ac.il (Fred Wiersma) (06/26/91)
Bruce (aka The Grand Master) writes: > OK > I am getting there. > As you all know by know > Trying to compile 1.6.16 on an IBM PS/2 286 > > Problems still: > I got kernel to compile by replacing sigaddset, sigismember, sigdelset, > and sigemptyset with the corresponding lines from the 1.5.10 kernel > (this occurs in system.c). > I could not do the same however in mm, becauase of the number of occurences > (signal.c, exec.c, main.c, break.c) and the complexity of some of those. > The old versions of these files use certain variables in the location > where the new versions use sig*, but said variables are not present > anywhere in the new version. > HELP!! > Why are sigaddset, sigdelset, sigemptyset, and sigismember undefined!?!?!?? Because AST forgot to include these in the 1.6.16 cdiffs, I think, but now you can ftp them from ftp.cs.vu.nl. I think they are in lib_other.shar.Z. > If you wanna see where they are they are in /usr/include/signal.h > There are defined like: > _PROTOTYPE (sigdelset, (sigset_t *_set) ); /* or something like that */ > > A friend of mine said that the a procedure defined with the _PROTOTYPE > call will be left unset if using a K&R compiler (That is what cc is right?) > > So how can I have these defined???? > cc on the pc is the ACK compiler which is K&R. If I remember correctly, there is a macro definition for PROTOTYPE which for ACK transforms a function definition to K&R functions. Try cpp on a program with PROTOTYP and see what it does.. > Is there anyone out there who got 1.6.16 to compile using the plain > 1.5.10 compiler?? > Yep, me... Only some test programs give errors, but I haven't had the time yet to look into it. > Ugh - this is really frustrating. > Three weeks I have been trying to compile 1.6.16 Off and on, about the same time for me. > If I do not get it straight soon, I am going to delete 1.6.16 and just > live with 1.5.10. When AST posted the 1.6.16 announcement, he wrote that, after getting bug reports etc. he might post the definite 1.6 version cdiffs to the net. You may wait for them. > > When is 2.0 due out??? > > Bruce Fred Wiersma SRONCH@HLERUL2.BITNET or wiersma@compass.LeidenUniv.nl
asg@sage.cc.purdue.edu (The Grand Master) (06/27/91)
In article <57242@nigel.ee.udel.edu> SRONCH%HLERUL2.BITNET@vm.biu.ac.il (Fred Wiersma) writes: } }Bruce (aka The Grand Master) writes: }> OK }> I am getting there. }> As you all know by know }> Trying to compile 1.6.16 on an IBM PS/2 286 }> }> Problems still: }> Why are sigaddset, sigdelset, sigemptyset, and sigismember undefined!?!?!?? } }Because AST forgot to include these in the 1.6.16 cdiffs, I think, but }now you can ftp them from ftp.cs.vu.nl. I think they are in }lib_other.shar.Z. They are not there. I lib_other.sh (which is what was there) and unpacked it, but there was no mention of sigemptyset, sigdelset, etc. } }> Is there anyone out there who got 1.6.16 to compile using the plain }> 1.5.10 compiler?? }> } }Yep, me... }Only some test programs give errors, but I haven't had }the time yet to look into it. Would you look for the defs of sig* that you have and send them to me? I would appreciate it. }> }> When is 2.0 due out??? Well??? Bruce --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
hp@vmars.tuwien.ac.at (Peter Holzer) (06/27/91)
asg@sage.cc.purdue.edu (The Grand Master) writes: >HELP!! >Why are sigaddset, sigdelset, sigemptyset, and sigismember undefined!?!?!?? >If you wanna see where they are they are in /usr/include/signal.h >There are defined like: >_PROTOTYPE (sigdelset, (sigset_t *_set) ); /* or something like that */ >A friend of mine said that the a procedure defined with the _PROTOTYPE >call will be left unset if using a K&R compiler (That is what cc is right?) In C you have to distinguish between definitions and declarations. A definition defines an object, i.e. you tell the compiler what type and contents the object has. A declaration just tells the compiler that somewhere an object of the given type is defined. So if the compiler finds the declaration sigdelset (); /* This is what the _PROTOTYPE macro produces on a K&R compiler*/ it just knows that somewhere a function returning int taking an unknown number of unknown parameters exists. It cannot produce code from this, because you don't tell it what sigdelset should do. The definition of sigdelset is in some library file and looks like sigdelset (_set) sigset_t *_set; { /* code */ } From this the compiler can actually produce code. If the the file containing the definition of an object is not linked to the files where the object is used (because you don't have the file, or forgot to include it in the library, or whatever), the linker naturally complains (At least for functions, it can produce variables of known type by itself and initialize them to zero). Hope to have cleared up things a little bit. Peter. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
sfreed@triton.unm.edu (Steven Freed CIRT) (06/28/91)
In article <13990@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: >Problems still: >I got kernel to compile by replacing sigaddset, sigismember, sigdelset, >and sigemptyset with the corresponding lines from the 1.5.10 kernel >(this occurs in system.c). Like I said in reply to someone elses plight.... You need to get the additional libs from whereever you got the update patches. >Is there anyone out there who got 1.6.16 to compile using the plain >1.5.10 compiler?? Just finished compiling, will start testing in about an hour. >Three weeks I have been trying to compile 1.6.16 >If I do not get it straight soon, I am going to delete 1.6.16 and just >live with 1.5.10. >When is 2.0 due out??? ***Flame ON Whoa!!! 1.6.16 is *BETA* !!!! If you want to play with it, you must expect the frustrations that come with with beta software. If you want to install it with a minimal amount of hassle then wait for the full release to come out. If you want a smooth clean install, go buy a Sun with the OS already installed on it. Sure, as long as we are trying to compile these updates with the old compiler and libs, there are going to be a few problems. The 2.0 C compiler, according to Andy is coming "soon". I can understand his reluctance to be pinned down to a specific date, but believe me, it will be soon. None the less, almost all the problems can be worked around with the sources that are available and a little creativity and effort. If you can't deal with this, then go back to 1.5.10 and wait. ***Flame OFF No, I am not going to elaborate any further on how I got everything to compile untill I've tested it to make sure it works. I really don't want to feel responsible for trashing my disk *and* someone elses because of something I posted. To give a hint, however, I edited about 70 of the libc.a source files. -- Steve. sfreed@ariel.unm.edu