I downloaded openssh-3.4p1.tar.gz from one of the London, UK mirrors, untared it, configured it with "./configure --prefix=/usr/local/pkg/openssh-3.4p1" and then tried to make and got: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/include -DSSHDIR=\"/usr/local/pkg/openssh-3.4p1/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/pkg/openssh-3.4p1/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/pkg/openssh-3.4p1/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/pkg/openssh-3.4p1/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/pkg/openssh-3.4p1/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/pkg/openssh-3.4p1/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c:65: warning: initialization from incompatible pointer type cipher.c:66: warning: initialization from incompatible pointer type cipher.c:70: warning: initialization from incompatible pointer type cipher.c:71: warning: initialization from incompatible pointer type cipher.c:72: warning: initialization from incompatible pointer type cipher.c:73: warning: initialization from incompatible pointer type cipher.c: In function `cipher_get_keyiv': cipher.c:610: `__func__' undeclared (first use in this function) cipher.c:610: (Each undeclared identifier is reported only once cipher.c:610: for each function it appears in.) cipher.c: In function `cipher_set_keyiv': cipher.c:667: `__func__' undeclared (first use in this function) cipher.c: In function `cipher_get_keycontext': cipher.c:706: warning: comparison of distinct pointer types lacks a cast cipher.c: In function `cipher_set_keycontext': cipher.c:721: warning: comparison of distinct pointer types lacks a cast make: *** [cipher.o] Error 1 It may be that I have done something wrong but it may also be that there is a problem with the tgz file.
i'm not sure. what does this show: $ grep HAVE___[Ff] config.h /* #undef HAVE___FUNCTION__ */ #define HAVE___func__ 1
The version of (g)cc being used by the reporter doesn't support the __func__ directive from the ISO C99 standard. See this web page for details: http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html A similar bug for openssh-3.1p1-6 for Red Hat Linux has more information: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=67621 And here's the patch attached to that bug that corrects the problem for older versions of gcc. https://bugzilla.redhat.com/bugzilla/showattachment.cgi?attach_id=65825 NOTE: I haven't looked at the source for openssh-3.4p1 so there could be an issue with checking for the availability of __func__ in the configure script that could be the cause of this issue. The patch above fixed the issue for me when building openssh-3.4p1-6 SRPM on Red Hat 6.2, though.
The logic we use is such: configure checks if __FUNCTION__ exists configure checks if __func__ exists And in defines.h we do: #if !defined(HAVE___func__) && defined(HAVE___FUNCTION__) # define __func__ __FUNCTION__ #elif !defined(HAVE___func__) # define __func__ "" #endif So if there is no possible way of doing __func__ we just set it to nothing. That way we still have code compatibility at the cost of readable debugging. I hate the whole __func__ vs __FUNCTION__ crap. I really don't like the fact we started depending on those. So the issue has to be in how configure is doing it's job.
I am embarrassed. I think this problem was almost entirely my fault and nothing to do with the OpenSSH system -- there is an issue with the configure system though. At the time of initially trying to build OpenSSH 3.4p1 I was using gcc 2.9.5 -- I have subsequently upgraded to 3.1. However, it transpired that 2.8.1 was also installed on the machine I was building OpenSSH on. Whilst gcc -v reported 2.9.5, this was due to some aliases and was not true of the gcc used by the more resticted path used within the make system. Thus the initial pass of ./configure found 2.9.5 and found all the necessary declarations/definitions, the actual compilation used 2.8.1 which did not and hence the problem. So although the actual error message is due to use of an inappropriate gcc, now removed, there is an issue here that the initial configuration used a compiler that was not used during tha actual compilation, i.e. there was a phase error that was not in control of the user, i.e. me. I was upgrading a large number of packages at the time I reported this problem and basically forgot to retract the bug when I rationalized my compilers (by installing 3.1 and removing everything else). Apologies for this, please forgive me.
Mass change of RESOLVED bugs to CLOSED