Tail of ngrep merge attempt: updating cache ./config.cache creating ./config.status creating Makefile make[1]: Entering directory `/var/tmp/portage/ngrep-1.41/work/ngrep-1.41/regex-0.12' gcc -g -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -I. -I. -c regex.c make[1]: Leaving directory `/var/tmp/portage/ngrep-1.41/work/ngrep-1.41/regex-0.12' gcc -march=pentium3 -O3 -pipe -DSTDC_HEADERS=1 -DRETSIGTYPE=void -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_IF_ETHER_H=1 -DHAVE_SLL=1 -DHAVE_LOOP=1 -DHAVE_802_11=1 -D_BSD_SOURCE=1 -D__FAVOR_BSD=1 -DLINUX=1 -DHAVE_DUMB_UDPHDR=1 -DHAVE_LIBPCAP=1 -DNEED_RESTART=1 -DPCAP_RESTART=pcap_restart -DSAFE_USER='"nobody"' -I. -I/usr/include -g -c ngrep.c ngrep.c: In function `process': ngrep.c:544: error: structure has no member named `source' ngrep.c:545: error: structure has no member named `dest' make: *** [ngrep.o] Error 1 Tail of tcpdump merge attempt: gcc -march=pentium3 -O3 -pipe -DHAVE_CONFIG_H -I. -I./missing -I/usr/include -c ./print-raw.c gcc -march=pentium3 -O3 -pipe -DHAVE_CONFIG_H -I. -I./missing -I/usr/include -c ./print-rip.c gcc -march=pentium3 -O3 -pipe -DHAVE_CONFIG_H -I. -I./missing -I/usr/include -c ./print-rx.c gcc -march=pentium3 -O3 -pipe -DHAVE_CONFIG_H -I. -I./missing -I/usr/include -c ./print-sctp.c In file included from print-sctp.c:54: /usr/include/netinet/in.h:83: error: syntax error before numeric constant print-sctp.c: In function `sctp_print': print-sctp.c:117: error: `IPPROTO_SCTP' undeclared (first use in this function) print-sctp.c:117: error: (Each undeclared identifier is reported only once print-sctp.c:117: error: for each function it appears in.) make: *** [print-sctp.o] Error 1 Reproducible: Always Steps to Reproduce: 1. emerge ngrep or 1. emerge tcpdump Actual Results: See Details. Expected Results: Merged successfully. Portage 2.0.49-r13-2 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r6, 2.4.20-gentoo-r7) ================================================================= System uname: 2.4.20-gentoo-r7 i686 Pentium III (Katmai) Gentoo Base System version 1.4.3.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://cudlug.cudenver.edu/gentoo/ http://oss.redundant.com/pub/gentoo http://adelie.polymtl.ca/ http://gentoo.chem.wisc.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 oss apm arts avi crypt cups encode foomaticdb gif imlib jpeg libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis pdflib png qt quicktime sdl spell svga truetype xml2 xmms xv zlib gdbm berkdb slang readline tcltk java gpm tcpd pam ssl perl python opengl -X -gtk -gnome -alsa -kde"
I sent an email to the ngrep author about what may be causing this, as I can replicate the bug on x86, sparc, and mips. Hopefully he'll have an answer to the problem.
Forgot to add, about the tcpdump issue, There already exists a bug for ti with a fix as well. It's Bug #25544. Give the fix in there a run and let me know how it goes.
This bug occurs during a test to see whether the old BSD-style udphdr struct is being used, or some newer one whose source I am unfamiliar with. This was done because of an intermediate build of redhat that basically had screwed up the consistency/method of being able to reliably determine which one was in use. The compile would complete if the configure.in test didn't conclude that the non-BSD struct was being employed. The configure test comes to this conclusion because of a subtle change in ``/usr/include/features.h'', which makes it insufficient to simply define __FAVOR_BSD && _BSD_SOURCE. Now, even if you define __FAVOR_BSD, ``features.h'' undefines it and will only set it back IFF _BSD_SOURCE is set AND _GNU_SOURCE is UNSET (the latter being a bit of behaviour that changed). The fix has been committed to ngrep CVS (would provide url but sf.net webcvs not responding at the moment) and simply consisted of adding ``#undef _GNU_SOURCE'' to the configure.in udp hdr test, after the *BSD definitions but before including ``netinet.h''.
The tcpdump fix seems to work fine. I checked the CVS for ngrep and added the appropriate line to my configure.in, but it seemed to have no effect. Any ideas?
I run Gentoo (x86 latest) and am completely up to date, and have been able to compile ngrep myself with no problems or issues. Can you give me a little more information about the system, that might pertain to why you're having this problem? Did you install things that otherwise would be masked out in a normal installation of Gentoo?
I've tried CFLAGS="-Wall" to get some more messages and got this: --START-- ... make[1]: Leaving directory `/var/tmp/portage/ngrep-1.41/work/ngrep-1.41/regex-0.12' gcc -Wall -DSTDC_HEADERS=1 -DRETSIGTYPE=void -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_IF_ETHER_H=1 -DHAVE_SLL=1 -DHAVE_LOOP=1 -DHAVE_802_11=1 -D_BSD_SOURCE=1 -D__FAVOR_BSD=1 -DLINUX=1 -DHAVE_DUMB_UDPHDR=1 -DHAVE_LIBPCAP=1 -DNEED_RESTART=1 -DPCAP_RESTART=pcap_restart -DSAFE_USER='"nobody"' -I. -I/usr/include -g -c ngrep.c ngrep.c: In function `main': ngrep.c:251: Warnung: implicit declaration of function `pcap_restart' ngrep.c:326: Warnung: operation on `s' may be undefined ngrep.c:435: Warnung: control reaches end of non-void function ngrep.c: In function `process': ngrep.c:495: Warnung: too many arguments for format ngrep.c:544: error: structure has no member named `source' ngrep.c:545: error: structure has no member named `dest' ngrep.c: In function `print_time_absolute': ngrep.c:776: Warnung: int format, __suseconds_t arg (arg 8) make: *** [ngrep.o] Fehler 1 ... --END-- Maybe a little help...
After deleting -D__FAVOR_BSD and -DHAVE_DUMP_UDPHDR from cflags in the Makefile, it compiles and works :-)
Created attachment 19947 [details, diff] patches ngrep.c to compile Here is a patch for ngrep.c to handle the "__BSD_FAVOR" syntax correctly In BSD style the stucture variables are called uh_sport/uh_dport, otherwise source/dest (see /usr/include/netinet/udp.h) This patch fixes this issue in the source of ngrep
The ngrep issue have been fixed, look at bug #32535. I am not sure if its the same for tcpdump.
Ok, here is a patch for tcpdump - I am not sure why, as I cannot see sys/in.h or such being included, or any defines causing this, but it works: -- --- tcpdump-3.7.2/print-sctp.c 2003-11-04 01:00:35.360767312 +0200 +++ tcpdump-3.7.2/print-sctp.c 2003-11-04 01:01:02.315669544 +0200 @@ -42,6 +42,8 @@ static const char rcsid[] = #include "config.h" #endif +#include <netinet/in.h> + #include <sys/param.h> #include <sys/time.h> #include <sys/socket.h> @@ -51,8 +53,6 @@ static const char rcsid[] = #include "sctpConstants.h" #include <assert.h> -#include <netinet/in.h> - #include <stdio.h> #include <string.h>
Ok, I missed the fix being given for tcpdump. Why is it not in yet?
This bug occurs from the configure.in's inability to properly discern which udphdr declaration to use. I am intent on fixing this bug, but I don't consider a patch to ngrep.c to solve the problem; rather a patch to configure.in that corrects whatever the condition is whereby it makes the wrong assumption about the dumb udphdr declaration is what is warranted here. I've had a few email exchanges with Georg M?ller <georgmueller@gmx.net>, but unfortunately his ISP uses MAPS's RBL/DUL/RSS dnsbl's (which are broken) and I am unable to send him email from home (I am on a cable modem, but his ISP thinks I'm on a dialup system). Georg, you might consider sending a complaint to your ISP. Regardless, it appears as though this bug manifests as a result of gcc 3.3.x, and might specifically be gcc 3.3.1. Here's what I do know: ngrep 1.41 does compile on 3.2.3 and every older gcc release. ngrep 1.41 does not compile for two people who use 3.3.1. ngrep 1.41 does compile on 3.3.2, with the possibly relevant caveat that I emerge'd 3.3.2 after 3.2.3, and used gcc-config to switch to 3.3.2 to test. I would appreciate if the reporter et al. could provide a little more detail and information around this issue. One useful datapoint would be for the reporter et al. to emerge an older version of gcc (say, gcc 3.2.3), gcc-config to it, and validate (or not) that ngrep compiles as it does for me. Thanks, --jordan
I do not know if you saw, but ngrep have been fixed (and its an configure fix)...
I did see other people's posts, but none of them are actually completely valid bugfixes: ngrep has been working for a very, very long time, and none of the solutions I saw posted (including the comma bug for the configure.in script) actually addressed anything that has been a real, consistent bug. In other words, the comma used to work properly and ngrep has been succesfully installed for a few years now, thus the behaviour/usage of AC_TRY_COMPILE has obviously changed since I first wrote that configure.in back in 2000. The configure script should have worked as advertised, since the confgiure was generated by a configure.in that was properly understood. I have found a few other problems with the configure.in script in terms of subtle things changing in pre-existing autoconf macros, which I've already corrected in CVS. But I don't think it addresses the real issue, which is why the original configure script (generated by a compatible autoconf/configure.in pair) stopped working. --jordan
Sorry for the late reply. The fact of the matter is that an unmodified configure as from the tarball (check bug #32535 for more background on AC_TRY_COMPILE and the comma issue) have a the test for 'a dumb udphdr declaration' with the includes _inside_ the main() function. This _used_ to work, but does not do so with later 3.3 gcc's. As for if the AC_TRY_COMPILE test is correct (first comma location), I really do not think it is. I do not 100% agree with bug #32535 in totally removing it (explanation below). From autoconf-2.1 info page: -- - Macro: AC_TRY_COMPILE (INCLUDES, FUNCTION-BODY, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]) Create a C, C++ or Fortran 77 test program (depending on which language is current, *note Language Choice::), to see whether a function whose body consists of FUNCTION-BODY can be compiled. For C and C++, INCLUDES is any `#include' statements needed by the code in FUNCTION-BODY (INCLUDES will be ignored if the currently selected language is Fortran 77). This macro also uses `CFLAGS' or `CXXFLAGS' if either C or C++ is the currently selected language, as well as `CPPFLAGS', when compiling. If Fortran 77 is the currently selected language then `FFLAGS' will be used when compiling. If the file compiles successfully, run shell commands ACTION-IF-FOUND, otherwise run ACTION-IF-NOT-FOUND. This macro does not try to link; use `AC_TRY_LINK' if you need to do that (*note Examining Libraries::). -- This tells us that all '#include <...' should be the _first_ argument of AC_TRY_COMPILE (not included with body like in ngrep's configure.in). Meaning a proper version of ngrep's configure will be after following patch is appplied: -- --- configure.in.az 2003-11-16 19:52:29.960546640 +0200 +++ configure.in 2003-11-16 19:52:42.053708200 +0200 @@ -179,7 +179,7 @@ AC_DEFINE(LINUX) AC_MSG_CHECKING(for a dumb udphdr declaration) - AC_TRY_COMPILE(, + AC_TRY_COMPILE( #ifndef __FAVOR_BSD #define __FAVOR_BSD #endif @@ -189,7 +189,7 @@ #endif #include <netinet/udp.h> - +, struct udphdr foo; unsigned short bar = foo.uh_sport; , -- Which will give us the following test in generated configure: -- --- configure.az 2003-11-16 19:55:57.423007552 +0200 +++ configure 2003-11-16 19:56:21.481350128 +0200 @@ -1763,8 +1763,6 @@ cat > conftest.$ac_ext <<EOF #line 1765 "configure" #include "confdefs.h" - -int main() { #ifndef __FAVOR_BSD #define __FAVOR_BSD #endif @@ -1775,12 +1773,13 @@ #include <netinet/udp.h> +int main() { struct udphdr foo; unsigned short bar = foo.uh_sport; ; return 0; } EOF -if { (eval echo configure:1784: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:1783: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* echo nope else -- which fixes the problem for gcc-3.3.x that breaks if you have #include for system headers in a function body (correct according to Jakub). Comments?
OK! I've fixed this in ngrep CVS. I will probably be doing a new point release in the next few days (have had a few other patches/bugfixes provided). Please let me know if there is a contact address @ gentoo.org that should receive release notices. Thanks again for the help! Best regards, --jordan
Hi, sorry again for late reply =) You can just mail to gcc-porting@gentoo.org if you get the next release out. Thanks and appreciated.
As for tcpdump, can anybody confirm that it seems that the patch for bug #25544 might have fixed it? I have gcc-3.3.2-r4, but also linux-headers-2.6.0, so it might confuse things ...
*** Bug 39778 has been marked as a duplicate of this bug. ***
ngrep-1.41 is marked stable these days and tcpdump does build, so this bug is resolved
