[privoxy-devel] [ ijbswa-Bugs-707467 ] 3.1: Compile problem unter NetBSD

[SourceForge.net <no...@so...>]

Bugs item #707467, was opened at 2003-03-21 12:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=707467&group_id=11118

Category: unix-specific
Group: version 3.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Todd Gruhn (tgruhn)
Assigned to: Andreas Oesterhelt (oes)
Summary: 3.1: Compile problem unter NetBSD

Initial Comment:
Whats going on here? Line 748 is before the last
"break" statement".
I tried declaring it but that doesn't appear to fix
anything...

I used the latest copy of the sources from the CVS tree...
OH I am using NETBSD-1.6.0 -- I wonder if that makes a
difference...

gcc -c -pipe -g -O2    -Wall -Ipcre   src/filters.c -o
obj/filters.o
gcc -c -pipe -g -O2    -Wall -Ipcre   src/gateway.c -o
obj/gateway.o
gcc -c -pipe -g -O2    -Wall -Ipcre   src/jcc.c -o
obj/jcc.o
src/jcc.c: In function `sig_handler':
src/jcc.c:748: `received_hup_signal' undeclared (first
use in this function)
src/jcc.c:748: (Each undeclared identifier is reported
only once
src/jcc.c:748: for each function it appears in.)
gnumake: *** [obj/jcc.o] Error 1
gandalf# 


/*********************************************************************
 *
 * Function    :  sig_handler 
 *
 * Description :  Signal handler for different signals.
 *                Exit gracefully on ABRT, TERM and  INT
 *                or set a flag that will cause the errlog
 *                to be reopened by the main thread on HUP.
 *
 * Parameters  :
 *          1  :  the_signal = the signal cause this
function to call
 *
 * Returns     :  - 
 *
 *********************************************************************/
static void sig_handler(int the_signal)
{
   switch(the_signal)
   {
      case SIGABRT:
      case SIGTERM:
      case SIGINT:
         log_error(LOG_LEVEL_INFO, "exiting by signal
%d .. bye", the_signal);
#if defined(unix)
         unlink(pidfile);
#endif /* unix */
         exit(the_signal);
         break;

/** static received_hup_signal; **/

      case SIGHUP:
         received_hup_signal = 1;
         break;         





----------------------------------------------------------------------

>Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-31 12:43

Message:
Logged In: YES 
user_id=5106

I was just wondering -- did we miss getting this fix into
the 3.0.2 release?

----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-27 18:40

Message:
Logged In: YES 
user_id=5106

Talk about the pleasant surprize -- the '--pidfile' problem
disappeared like I
suspected.  Privoxy also started looking for the jarfiles.

Todd

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-27 17:50

Message:
Logged In: YES 
user_id=78811




----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-27 17:30

Message:
Logged In: YES 
user_id=5106

I don't know what you did, but this compile went off 
without any hitches...

I'm gonna see if it also fixed the --pidfile problem (it'd
be cool it it did :-)  )

Todd

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-27 16:21

Message:
Logged In: YES 
user_id=78811

Todd,

thanks for your update. That's really cool of gcc on NetBSD to
define neither "unix" nor "__unix__". Anyway, have extended
the test to include "__NetBSD__" now.

Could you please repeat the 5-step test one last time to make
sure the problem is really gone?

Lets handle the --pidfile trouble ion a separate bug report
please.
In any case, we'd need the log messages where Privoxy should
complain that it can't open a pid file and why.

Thanks!

----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-27 16:10

Message:
Logged In: YES 
user_id=5106

Here it is. I also discovered another thing that could very
well be related:
the "--pidfile" option does not work in my rc.d script,
regardless of how its
entered. If I can't get this right, then the 'stop' case
fails, also restart
fails,  because restart calls stop, and then it calls start
the start case...


debian                     parsers.c                  win32.h
$ uname -a
NetBSD gandalf.wanderer.us 1.6 NetBSD 1.6 (GENERIC-ADP.950)
#0: Wed Mar 26 15:31:2
9 EST 2003    
to...@ga...:/usr/src/sys/arch/i386/compile/GENERIC-ADP
.950 i386
$ 
$ gcc --version
2.95.3
$ 
$ touch foo.c; gcc -E -dM foo.c; rm foo.c
#define __i386__ 1 
#define __NetBSD__ 1 
#define __i386 1 
#define __GNUC_MINOR__ 95 
#define i386 1 
#define __GNUC__ 2 
#define __ELF__ 1 
$ 


----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-27 14:29

Message:
Logged In: YES 
user_id=78811

Todd,

the "int received_hup_signal;" is indeed needed. It is therefore present
in line 704 of jcc.c. It is, however, located in a block of statements that
is only included by the prepocessor if a macro called "unix" is defined.

Now the interesting question is: Why isn't that macro defined on your
machine although it should be, especially since our lastest change?

To help answer that, could you please issue the following commands
and post the result here?

uname -a
gcc --version 
touch foo.c; gcc -E -dM foo.c; rm foo.c

Thanks!


----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-26 03:37

Message:
Logged In: YES 
user_id=5106

NOPE
It broke at jcc.c:752

the way I got around that was to add the following
declaration around
jcc.c:737 :

int received_hup_signal;

jcc.c again compiled fine when I added this.

Is there a reason this did not get added? Can someone
explain your coding
standard -- I would assume you would use "int" here because
recieving or
not receiving something ==> a boolean and 0/1 are ints. I
rarely program
in C and my ANSI C book is  about 10yrs old.

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-26 02:53

Message:
Logged In: YES 
user_id=78811

Yes - sorry about the comment.

The reason we are so stubborn about this test is this:
It's often easy to kludge things to work locally on one
specific machine. The Privoxy code and build system
are made to automatically detect and do the right thing
on a variety of platforms, so we're interested in if the
detection works, not how it can be bypassed.


----------------------------------------------------------------------

Comment By: David Schmidt (david__schmidt)
Date: 2003-03-26 02:31

Message:
Logged In: YES 
user_id=249980

Todd -

Sorry, we're a little stressed around here - we're trying to
get 3.0.1 out the door.  

Would you please try this little test for us?  Do these
commands exactly... note that the one starting "cvs -z3" is
one line, though it spans two below:

  create a fresh, empty directory, then cd to it
  cvs -d:pserver:ano...@cv...:/cvsroot/ijbswa login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/ijbswa co
-r v_3_0_branch current
  cd current
  make

Is this successful?

- David

----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-26 02:25

Message:
Logged In: YES 
user_id=5106

I don't think I said I chose not to help you -- but the goal
was to make this 
thing compile on NetBSD. If it compiles with this little
declaration, does the 
other code matter? And where exactly doed it go (I assume
you refer to
Dave Schmidts code)?

I also created a rc.d script to run privoxy on NetBSD where
shall I put it?

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-25 17:14

Message:
Logged In: YES 
user_id=78811

OK, since Todd has chosen not to help us, I'll let this pend out as
"presumably fixed". 

Anyone willing and able to type five commands for us on NetBSD
is welcome to confirm the fix or re-open otherwise.



----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-22 19:21

Message:
Logged In: YES 
user_id=5106

HA HA! I now have a privoxy binary! Ya wont believe what I did!:

At jcc.c:741 I added the following declaration:

int received_hup_signal; 

The compile then completed :-)


----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-22 13:09

Message:
Logged In: YES 
user_id=78811

Todd,

..excuse my insisting, but you would really help me a lot with fixing
this bug for your platform which I otherwise don't have access
to, by trying out exactly what I proposed. Since the patch is in CVS
now, all you'd need to do is:

  create a fresh, empty directory, then cd to it
  cvs -d:pserver:ano...@cv...:/cvsroot/ijbswa login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/ijbswa co -r v_3_0_branch current
  cd current
  make

and report the result. Thanks!

BTW, make clobber serves to remove config.h.in and config.h, which is necessary,
since the cpp code is propagated to config.h by autoheader and then configure.


----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-21 22:06

Message:
Logged In: YES 
user_id=5106

I just noticed Andreas' repost of Shamims post -- so I tried
it: I get the same 
result with privoxy-3.0.0-stable. When I searched through
acconfig.h I could
not find where "unix" was defined -- so I added the following:

#if defined(__unix__) ||defined(NetBSD) &&!defined(unix)
#define unix 1
#endif

Here is what the compiler said:

gandalf# gnumake
gcc -c -pipe -g -O2    -Wall -Ipcre   jcc.c -o jcc.o
jcc.c: In function `sig_handler':
jcc.c:708: `received_hup_signal' undeclared (first use in
this function)
jcc.c:708: (Each undeclared identifier is reported only once
jcc.c:708: for each function it appears in.)
jcc.c:708: warning: statement with no effect
gnumake: *** [jcc.o] Error 1


----------------------------------------------------------------------

Comment By: Todd Gruhn (tgruhn)
Date: 2003-03-21 19:54

Message:
Logged In: YES 
user_id=5106

I think I know one of your problems: uname returns "NetBSD"
-- they changed
the symbol used for the system in the compiler about a year
ago...

At acconfig.h:448 I changed the line like so:
#if defined(__unix__) || defined(NetBSD) &&  !defined(unix)
#define unix 1
#endif

but the error persists

Whats the deal with "make clobber" my system chokes on it...

I have the feeling you will end up saying something like

#if defined(unix) && defined(NetBSD)
  {
    Then doit this way...
  }
#endif

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-21 14:56

Message:
Logged In: YES 
user_id=78811

Have now added the proposed fix to acconfig.h, since defining unix
based on __unix__ is reported to work on OpenBSD and can't hurt,
anyway.

I'd still like to have a confirmation whether or not this works (read:
__unix__ is defined) on FreeBSD as well.

Todd: Note that you need to "make clobber" for the change to take effect.
 

----------------------------------------------------------------------

Comment By: David Schmidt (david__schmidt)
Date: 2003-03-21 13:24

Message:
Logged In: YES 
user_id=249980

You need to compile this block in:

#if defined(unix) || defined(__EMX__)    
const char *basedir;
const char *pidfile = NULL;
int received_hup_signal = 0;
#endif /* defined unix */

So you either need to be #deffing unix or stick another
BSD-specific #ifdef in there.  I'm thinking you'll have
other problems compiling if you don't have 'unix' defined,
though.

- David

----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-21 13:18

Message:
Logged In: YES 
user_id=78811

It looks as if the preprocessor symbol "unix" wasn't defined
on NetBSD and hence the variable  received_hup_signal 
undefined.

Something similar was reported for OpenBSD last year, but 
somehow not acted upon. Since the compile farm NetBSD box
is out of service, could you do us a favour and verify that

a) The problem exists also in the stable branch (the version
   you checked out from CVS has many more problems -- to
   get the stable branch use -r v_3_0_branch when checking
   out) ?

b) If so, if adding this to acconfig.h, and then doing ./configure
   again, solves the problem:

/*
 * On OpenBSD, gcc doesn't define the cpp symbol unix; it defines __unix__
 */
#if defined(__unix__) && !defined(unix)
#define unix 1
#endif

Credit:This was originally proposed by Rev. Shamim Mohamed D.D.
on the developers list on Mon, 27 May 2002.


----------------------------------------------------------------------

Comment By: Andreas Oesterhelt (oes)
Date: 2003-03-21 13:08

Message:
Logged In: YES 
user_id=78811

Turning into bug report.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=707467&group_id=11118