jeffs@wjvax.UUCP (Jeffery Siou) (04/12/89)
First things first,I know very little about C programming except how to compile. While trying to compile 'gone' I got the following error after typing 'Make': cc -O gone gone.c "gone.c", line 170: SIGUSR2 undefined This was after I applied the patch recently posted. This problem occured also before applying posted patch. I'm running BSD 4.2. I looked in the '/usr/include/signal.h' file for "SIGUSR2", but it wasn't there. There were alot of other "SIG___.." there, but not "SIGUSR2". If I knew what "SIGUSR2" should be defined to, then I could put a copy of '/usr/include/signal.h' in the directory I trying to compile gone in, then add something to signal.h like: #define SIGUSR2 ____ and then change gone.c to: #include <signal.h> to #include "signal.h" then try to re-compile. Is there an easy solution to this for a person that knows little to nothing about C programming except how to compile. Any help greatly appreciated. Thanks in advance. +---------------------------------------------------------------------------+ | jeffery siou | | ...!{ !decwrl!qubix, ames!oliveb!tymix, pyramid}!wjvax!jeffs | | | | the above opinions are mine alone and not, in any way, those of WJ. | | | +---------------------------------------------------------------------------+ |
shirono@hcx3.SSD.HARRIS.COM (04/20/89)
SIGUSR2 is a signal reserved for use by the user in System V. From Release 3.2 for the 3B2, it is #define SIGUSR2 17 /* user defined signal 2 */ Notice, however, that this has to be closely tied in with the kernel. As a matter of fact, in vanilla 4.2 BSD, signal 17 is SIGSTOP, which, as per sigvec(2), "cannot be caught, blocked or ignored." Since you seem to have little experience with C programming and UNIX internals, I would suggest you find someone more knowledgeable. It seems that what you need to do is analyze the code, find out what signals must be left alone (either because the program itself uses them to alter its behavior or because the kernel might post said signal in response to an outside event, and confuse your program). One possibility, if the program does not write to pipes at all (either by its own choice or from writing to the standard output), then you could use SIGPIPE. It is a VERY UGLY way of doing this, but, without knowing what the code does, it is all I can suggest at this point. --Roberto ______________________________________________________________________________ || Internet: shirono@ssd.harris.com Roberto Shironoshita || Harris Corporation || ...!novavax---\ Computer Systems Division || UUCP: ...!uunet-------!hcx1!shirono || ...!mit-eddie-/ ------------------------------------------------------------------------------ DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.
guy@auspex.auspex.com (Guy Harris) (04/23/89)
>SIGUSR2 is a signal reserved for use by the user in System V. >From Release 3.2 for the 3B2, it is > > #define SIGUSR2 17 /* user defined signal 2 */ And in 4.3BSD, where it's #define SIGUSR2 31 /* user defined signal 2 */ >Since you seem to have little experience with C programming and UNIX >internals, I would suggest you find someone more knowledgeable. It seems >that what you need to do is analyze the code, find out what signals must be >left alone... ...or try just #defining SIGUSR2 and 31 and see how it goes. If the code is supposed to work under 4.3BSD, this will probably fix that part, although there may be other 4.3BSDisms not in 4.2BSD that it depends on. If the code wasn't made to work under 4.3BSD, you may have more work to do (or you may just get lucky).