From mouse Thu Jun 5 11:48:29 2008 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA02118 for mouseware; Thu, 5 Jun 2008 11:48:29 -0400 (EDT) Received: from c-0500.emailmediator.com (c-0500.emailmediator.com [64.85.162.118]) by Sparkle.Rodents.Montreal.QC.CA via TCP with SMTP id "MXHLRL.jDgm.CBn"; 5 Jun 2008 11:47:33 -0400 (EDT, 15:47:33 GMT) Received: from pool-71-123-170-155.dllstx.dsl-w.verizon.net ([71.123.170.155] helo=reedmedia.net) by c-0500.emailmediator.com with esmtpa (Exim 4.67) (envelope-from ) id 1K4HeF-00075V-LM for mouseware@rodents.montreal.qc.ca; Thu, 05 Jun 2008 11:45:08 -0400 Received: from reed@reedmedia.net by reedmedia.net with local (mailout 0.17) id 17646-1212680708; Thu, 05 Jun 2008 10:45:08 -0500 Date: Thu, 5 Jun 2008 10:45:08 -0500 (CDT) From: "Jeremy C. Reed" To: mouseware@rodents.montreal.qc.ca Subject: building mousessh-20080527 issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The following are some experiences on NetBSD and DragonFly with different versions of gcc and pcc. I have: gcc (GCC) 4.1.3 20080202 prerelease (NetBSD nb1 20080202) NetBSD/amd64 4.99.55 The error is tx:moussh-20080527$ make gcc -g -DNEW_CMSG_INTERFACE -o lcs-cvt lcs-cvt.c lcs-cvt.c: In function 'get_token': lcs-cvt.c:475: error: invalid storage class for function 'tokc' lcs-cvt.c:480: error: invalid storage class for function 'endbuf' lcs-cvt.c:485: error: invalid storage class for function 'skip_string' lcs-cvt.c:502: error: invalid storage class for function 'done' lcs-cvt.c:507: error: invalid storage class for function 'skip_number' *** Error code 1 I saw your Makefile and INSTALL notes about labeled control structure in your gcc, but I don't understand this nor do I know if it is related. Appears to be a gcc 3 versus 4 issue. As another data point, latest pcc doesn't like it either: bash-3.2$ USE_CC=/home/reed/pcc-pcc/bin/pcc bmake /home/reed/pcc-pcc/bin/pcc -g -o lcs-cvt lcs-cvt.c lcs-cvt.c, line 475: syntax error lcs-cvt.c, line 481: nbuf undefined lcs-cvt.c, line 503: buf undefined lcs-cvt.c, line 503: nbuf undefined lcs-cvt.c, line 503: warning: implicit conversion of argument 1 due to prototype lcs-cvt.c, line 570: nbuf undefined lcs-cvt.c, line 570: buf undefined lcs-cvt.c, line 570: illegal indirection lcs-cvt.c, line 591: syntax error lcs-cvt.c, line 591: array size not constant lcs-cvt.c, line 591: bad declaration in ansi function lcs-cvt.c, line 591: invalid function definition lcs-cvt.c, line 591: array of functions is illegal lcs-cvt.c, line 591: redeclaration of tok_pushbuf lcs-cvt.c, line 591: syntax error lcs-cvt.c, line 592: bad declaration in ansi function lcs-cvt.c, line 592: invalid function definition lcs-cvt.c, line 593: bad declaration in ansi function lcs-cvt.c, line 593: invalid function definition lcs-cvt.c, line 594: bad declaration in ansi function lcs-cvt.c, line 594: invalid function definition lcs-cvt.c, line 596: bad declaration in ansi function lcs-cvt.c, line 596: invalid function definition lcs-cvt.c, line 596: bad declaration in ansi function lcs-cvt.c, line 596: redeclaration of get_in lcs-cvt.c, line 596: syntax error lcs-cvt.c, line 597: syntax error lcs-cvt.c, line 597: bad declaration in ansi function lcs-cvt.c, line 597: invalid function definition lcs-cvt.c, line 597: redeclaration of in_loc lcs-cvt.c, line 599: bad declaration in ansi function lcs-cvt.c, line 599: redeclaration of lineno_line lcs-cvt.c, line 599: compiler error: too many errors *** Error code 1 So I used gcc 3.4.6. make failed to handle gen-verbose-bits so did manually: /usr/pkg/gcc34/bin/gcc -o gen-verbose-bits gen-verbose-bits.c ./gen-verbose-bits > verbose-bits.h And now new error: tx:moussh-20080527$ USE_CC=/usr/pkg/gcc34/bin/gcc make /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -E alg-comp-zlib.c -o _.i && ./lcs-cvt _.i && /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -c _.i -o alg-comp-zlib.o /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -E alg-enc-3des.c -o _.i && ./lcs-cvt _.i && /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -c _.i -o alg-enc-3des.o alg-enc-3des.c: In function `enc_3des_cbc_init_enc': alg-enc-3des.c:29: error: `ENCRYPT' undeclared (first use in this function) alg-enc-3des.c:29: error: (Each undeclared identifier is reported only once alg-enc-3des.c:29: error: for each function it appears in.) alg-enc-3des.c: In function `enc_3des_cbc_init_dec': alg-enc-3des.c:49: error: `DECRYPT' undeclared (first use in this function) alg-enc-3des.c: In function `enc_3des_cbc_process': alg-enc-3des.c:82: error: `ENCRYPT' undeclared (first use in this function) alg-enc-3des.c:92: error: `DECRYPT' undeclared (first use in this function) alg-enc-3des.c: In function `enc_3des_ctr_process': alg-enc-3des.c:161: error: `ENCRYPT' undeclared (first use in this function) *** Error code 1 I also tested on DragonFly. Its make(1) complains: $ make "Makefile", line 11: Malformed conditional ("${OS}" == "NetBSD" && ${OSREV:C/\..*//} > 1) "Makefile", line 13: if-less endif "Makefile", line 93: Malformed conditional ("$(UNAME_R)" == "1.4T") "Makefile", line 97: if-less endif make: fatal errors encountered -- cannot continue Using bmake (NetBSD pkgsrc version) gets to lcs-cvt.c errors above. gcc (GCC) 4.1.2 (DragonFly) So DragonFly has environment variable CCVER to choose cc. $ CCVER=gcc34 bmake gcc -g -o lcs-cvt lcs-cvt.c gcc -g -E alg-comp-none.c -o _.i && ./lcs-cvt _.i && gcc -g -c _.i -o alg-comp-none.o gcc -g -E alg-comp-zlib.c -o _.i && ./lcs-cvt _.i && gcc -g -c _.i -o alg-comp-zlib.o In file included from alg-comp-zlib.c:56: verbose.h:8:26: verbose-bits.h: No such file or directory *** Error code 1 So lcs-cvt.c compiles fine with gcc (GCC) 3.4.6 [DragonFly] (propolice, visibility). I don't know why the verbose-bits.h was not generated via Makefile. So I generated manually: $ CCVER=gcc34 gcc -o gen-verbose-bits gen-verbose-bits.c $ ./gen-verbose-bits > verbose-bits.h $ CCVER=gcc34 bmake gcc -g -E alg-comp-zlib.c -o _.i && ./lcs-cvt _.i && gcc -g -c _.i -o alg-comp-zlib.o gcc -g -E alg-enc-3des.c -o _.i && ./lcs-cvt _.i && gcc -g -c _.i -o alg-enc-3des.o alg-enc-3des.c:3:17: des.h: No such file or directory *** Error code 1 I will stop there on DragonFly as I have different des.h -- need to look further. Later I will try on a Linux system. From mouse Thu Jun 5 12:55:41 2008 Return-Path: Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA02604; Thu, 5 Jun 2008 12:55:41 -0400 (EDT) From: der Mouse Message-Id: <200806051655.MAA02604@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 5 Jun 2008 12:30:39 -0400 (EDT) To: mouseware@rodents.montreal.qc.ca Subject: Re: building mousessh-20080527 issues In-Reply-To: References: > The following are some experiences on NetBSD and DragonFly with > different versions of gcc and pcc. Ooo, thank you very much. > gcc (GCC) 4.1.3 20080202 prerelease (NetBSD nb1 20080202) > NetBSD/amd64 4.99.55 > gcc -g -DNEW_CMSG_INTERFACE -o lcs-cvt lcs-cvt.c > lcs-cvt.c: In function 'get_token': > lcs-cvt.c:475: error: invalid storage class for function 'tokc' > lcs-cvt.c:480: error: invalid storage class for function 'endbuf' > lcs-cvt.c:485: error: invalid storage class for function 'skip_string' > lcs-cvt.c:502: error: invalid storage class for function 'done' > lcs-cvt.c:507: error: invalid storage class for function 'skip_number' > *** Error code 1 Oh, ick. I need to update the lcs-cvt that's included with moussh. In the meantime, you can just take the lcs-cvt.c from the localsrc/lcs-cvt/ stuff. Or (I just diffed the two), you can just manually remove the "static"s from the function definitions in question. > I saw your Makefile and INSTALL notes about labeled control structure > in your gcc, but I don't understand this nor do I know if it is > related. It is not. This comes from my use of nested functions. gcc has changed its mind multiple times about what the correct ways to declare and define nested functions are; the version of lcs-cvt.c in the moussh tree uses an older paradigm than your gcc likes. > As another data point, latest pcc doesn't like it either: Not surprising; I think pcc doesn't do nested functions at all. > /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -E alg-enc-3des.c -o _.i > && ./lcs-cvt _.i && /usr/pkg/gcc34/bin/gcc -g -DNEW_CMSG_INTERFACE -c > _.i -o alg-enc-3des.o > alg-enc-3des.c: In function `enc_3des_cbc_init_enc': > alg-enc-3des.c:29: error: `ENCRYPT' undeclared (first use in this > function) At a guess, you're getting some other , possibly one from your OS, rather than the one from my libdes. As the INSTALL file notes of the crypto code, .... If you have existing code that implements the relevant crypto algorithms, it will probably be fairly simple to write a glue layer to use it; you probably will need a glue layer, though, since my code was not written with API-compatibility with any other code as a goal. > I also tested on DragonFly. Its make(1) complains: > $ make > "Makefile", line 11: Malformed conditional ("${OS}" == "NetBSD" && > ${OSREV:C/\..*//} > 1) > "Makefile", line 13: if-less endif > "Makefile", line 93: Malformed conditional ("$(UNAME_R)" == "1.4T") > "Makefile", line 97: if-less endif > make: fatal errors encountered -- cannot continue This is ringing some faint bells. I think there was a bug in make when comparing two double-quoted strings in a .if; perhaps it was an ancestral bug that dragonfly inherited? I wonder if there's a way to do that test that doesn't upset legacy makes. Certainly from one point of view, "fix your make" is a defensible stance, but it's rather more strident than helpful. You can always deal with it manually, if need be; see the comment in the Makefile four lines above the relevant .if.... > gcc -g -E alg-enc-3des.c -o _.i && ./lcs-cvt _.i && gcc -g -c _.i -o > alg-enc-3des.o > alg-enc-3des.c:3:17: des.h: No such file or directory To me, this definitely pushes up the plausibility of my theory above about getting the wrong . I'll certainly update the lcs-cvt.c in the moussh distribution - probably not until tonight at the earliest, though. The Makefile conditionals, I'm not sure what to do about. I'd prefer to use a test that works with dragonfly's make as well as netbsd's, if we can find some such test. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse Fri Jun 6 00:13:33 2008 Return-Path: Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA06719; Fri, 6 Jun 2008 00:13:33 -0400 (EDT) From: der Mouse Message-Id: <200806060413.AAA06719@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Fri, 6 Jun 2008 00:12:17 -0400 (EDT) To: mouseware@rodents.montreal.qc.ca Subject: Re: building mousessh-20080527 issues In-Reply-To: <200806051655.MAA02604@Sparkle.Rodents.Montreal.QC.CA> References: <200806051655.MAA02604@Sparkle.Rodents.Montreal.QC.CA> I wrote > Oh, ick. I need to update the lcs-cvt that's included with moussh. Now done - moussh is now at 20080606. This update of lcs-cvt.c is the only change from the previous version. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From mouse Mon Jun 9 00:59:11 2008 Return-Path: Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA01365; Mon, 9 Jun 2008 00:59:11 -0400 (EDT) From: der Mouse Message-Id: <200806090459.AAA01365@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 9 Jun 2008 00:55:44 -0400 (EDT) To: mouseware Subject: new moussh After walking a friend through a moussh build, I have a new version, 20080609, up for FTP. Changes in this version: - Update the list of known include-file bugs in INSTALL. - client.c and server.c use NI_WITHSCOPEID, but only client.c has a workaround for systems without it. Move this into an include file (withscopeid.h) and make client.c and server.c use it. - Update the NO_X11 code in x.c to match the prototype in x.h (and the non-NO_X11 version). der Mouse From mouse Mon Jun 9 02:13:01 2008 Return-Path: Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA02033; Mon, 9 Jun 2008 02:13:01 -0400 (EDT) From: der Mouse Message-Id: <200806090613.CAA02033@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 9 Jun 2008 02:00:13 -0400 (EDT) To: mouseware Subject: more updates libdes, now at 20080609. Coverity found an uninitialized variable; _it_ wasn't really a bug, but it pointed up a related bug. Fixed. libdsa, now at 20080609. Coverity found a resource leak. Fixed. moussh, still 20080609 - previous update failed to include fix for another Coverity-found resource leak. Not a serious one - a few hundred bytes per kex, at most - but still, a should-be-fixed. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B