http://bugzilla.mindrot.org/show_bug.cgi?id=320 ------- Additional Comments From stevesk at pobox.com 2002-07-18 14:24 ------- i'm not sure. what does this show: $ grep HAVE___[Ff] config.h /* #undef HAVE___FUNCTION__ */ #define HAVE___func__ 1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=320 ------- Additional Comments From ddkilzer at theracingworld.com 2002-07-19 05:49 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=320 ------- Additional Comments From mouring at eviladmin.org 2002-07-19 06:40 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=320 russel at russel.org.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From russel at russel.org.uk 2002-07-30 08:57 ------- 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.