[tcpdump-workers] Libpcap build error
Hello: I am trying to build libpcap for QNX 4.25, and am experiencing the following error: Unable to open 'ifaddrs.h' The configure script reports: checking ifaddrs.h usability... yes checking ifaddrs.h presence... no checking for ifaddrs.h... no What can I do about this? (The file does not exist.) Thanks, Paul Thomas - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 10:02 AM, Paul Thomas wrote: The configure script reports: checking ifaddrs.h usability... yes checking ifaddrs.h presence... no checking for ifaddrs.h... no What can I do about this? (The file does not exist.) Ask QNX; at least according to this page: http://www.qnx.com/developers/docs/momentics_nc_docs/neutrino/lib_ref/ g/getifaddrs.html getifaddrs() behaves like the getifaddrs() on some UN*Xes, and requires that you include ifaddrs.h, so presumably, at least in Neutrino, it exists. Now, that's Neutrino, not QNX4, and the page at http://www.qnx.com/developers/qnx4/index.html indicates that Neutrino is later than QNX4, so perhaps that documentation doesn't apply. Perhaps you have to install some package to get the ifaddrs.h include file. Note that libpcap includes no explicit QNX support. If somebody has QNX support, it would be Greatly Appreciated Indeed if they'd contribute it, so that we can make it part of the distribution, and make any changes to it that are required by libpcap changes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 12:15 PM, Paul Thomas wrote: From the TCP/IP Library Reference / System Library Functions Manual If that's the QNX4 documentation, then... SYNOPSIS #include sys/types.h #include sys/socket.h #include ifaddrs.h ...I would infer that QNX4 - or its development kit, if that's where header files come from, or wherever header files for whichever library getifaddrs() is in come from - is *supposed* to have ifaddrs.h as one of the header files, so you should ask QNX what the problem is. The getifaddrs() function first appeared in BSDI BSD/OS. The function is supplied on OpenBSD since OpenBSD 2.7. H So now I must scarf this file from an OpenBSD distro so that I can continue and build libpcap 0.8.3 for QNX 4.25 ?? No, you should scarf it from wherever QNX put it (assuming they didn't forget to include it, in which case you should ask QNX-the-company where you should get it from in order to fix the problem). I suspect The function is supplied on OpenBSD since OpenBSD 2.7. really means we took the OpenBSD man page and used that as our man page, and forgot to fix the HISTORY section not to somewhat-irrelevantly mention OpenBSD. (Whether they took the *implementation* from OpenBSD or not is another matter.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
If that's the QNX4 documentation, then... SYNOPSIS #include sys/types.h #include sys/socket.h #include ifaddrs.h ...I would infer that QNX4 - or its development kit, if that's where header files come from, or wherever header files for whichever library getifaddrs() is in come from - is *supposed* to have ifaddrs.h as one of the header files, so you should ask QNX what the problem is. Unfortunately, there is no connection between the quoted Man-Page-snippet and QNX. Consequently, I do not expect that there would be any support from QNX-the-company. That would be different if this were QNX6 (Neutrino/Momentics), which suggests the possibility that I might be able to get the missing file(s) from that source as well as OpenBSD (which is free, or even FreeBSD for that matter). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Is the getifaddrs() you're using part of QNX4, or is it
from some add-on library, e.g. taking the eCos implementation
and porting it to QNX4?
getifaddrs() is not part of QNX4. There is no connection whatsoever.
It is utilized in the libpcap file, 'fad-getad.c'.
This source file is called out explicity in libpcap 0.8.3's
configure-generated Makefile as:
FSRC = fad-getad.c
I am absolutely dumb-founded that the maintainers of libpcap would
have this code, and thereby _assume_ that the supporting file(s) would
already exist
on the developer's computer!
#include ifaddrs.h
...
if (getifaddrs (ifap) !=0) {
Its almost unbelievable!
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Here is the relevant output, from config.log: Is there earlier checking for getifaddr output in config.log? configure:3849: checking for getifaddrs configure:3899: cc -o conftest -g -O2 conftest.c 5 Warning(1028): getifaddrs_ is an undefined reference file conftest.o(/home/pthomas/libpcap-0.8.3/conftest.c): undefined symbol getifaddrs_ configure:3902: $? = 0 configure:3905: test -s conftest configure:3908: $? = 0 configure:3919: result: yes - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 1:23 PM, Paul Thomas wrote: Is the getifaddrs() you're using part of QNX4, or is it from some add-on library, e.g. taking the eCos implementation and porting it to QNX4? getifaddrs() is not part of QNX4. There is no connection whatsoever. It is utilized in the libpcap file, 'fad-getad.c'. This source file is called out explicity in libpcap 0.8.3's configure-generated Makefile as: FSRC = fad-getad.c Then either 1) your system somehow has a getifaddrs() or 2) the test for getifaddrs() somehow succeeded without it being present. We'd have to see the config.log file from your system to see how that happened. I checked in a change to 1) use the stub version of pcap_findalldevs() on platforms on which we don't support packet capture and 2) have the configure script fail on platforms with getifaddrs() but no usable ifaddrs.h. Change 1) will probably make the current CVS version configure, at least, on QNX4, unless, somehow, the configure script manages to find a packet capture mechanism it supports. I am absolutely dumb-founded that the maintainers of libpcap would have this code, and thereby _assume_ that the supporting file(s) would already exist on the developer's computer! The configure script does *NOT* assume that getifaddrs() exists on the developer's computer. Until my recent checkin, however, it *did* assume that if getifaddrs() existed in any of whatever libraries the AC_CHECK_FUNC() autoconf macro tested, ifaddrs.h would exist on the developer's computer, because in all systems we'd seen, getifaddrs() was explicitly documented as using ifaddrs.h. It now checks whether it exists, and fails if it doesn't, because that either means that 1) getifaddrs() is a system API and, when the system was installed, not all of the header files necessary for development were installed; 2) getifaddrs() is in a third-party library and, when that library was installed, not all of the header files necessary for development were installed; 3) ifaddrs.h was installed, but the configure script needs to search in some additional directory for it - which means it would need to set up the Makefile to search in that directory as well; 4) whoever provided the implementation of getifaddrs() made it incompatibly use a header file other than ifaddrs.h; 5) the getifaddrs() is not a BSD-style getifaddrs(); and in all of those cases either the user needs to figure out what needs to be done and do it (in cases 1) and 2)) or we need to figure out, with information supplied by the user, what needs to be done and do it (in cases 3), 4), and 5)). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 3:40 PM, Paul Thomas wrote:
There is a wcc option, -we (treat all warnings as errors) described
as
follows.
By default, the compiler continues to create an object file when
there are
warnings produced. This option can be used to treat all warnings as
errors,
thereby preventing the compiler from creating an object file if there
are
warnings found within a module.
'cc' provides for -f{option} which allows us to pass -f option to
wcc.
So, cc -f we should do the trick?
Unfortunately, it'll turn *all* warnings into errors; the only warnings
I want turned into errors are the warnings for undefined references, as
there might be other warnings that are harmless *and* difficult if not
impossible to eliminate in a configure script.
That's probably a warning from the linker - i.e., it's presumably
produced after the object files have been created. Is there an option
to get the linker to fail with undefined refeerences?
And is the linker part of the Watcom C compiler?
Also, if there is a way of getting the linker to fail with undefined
references, so that we could, in theory, have the configure script use
an option to make it do so:
What compilers are used with QNX? There's probably a GCC port; is
there any significant non-GCC compiler other than Watcom?
Is there a
host_os=???
line in the config.log file, and what's the ??? value? I.e., what does
host_os get set to on QNX?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 2:47 PM, Paul Thomas wrote: Here is the relevant output, from config.log: Is there earlier checking for getifaddr output in config.log? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 3:10 PM, Paul Thomas wrote: configure:3849: checking for getifaddrs configure:3899: cc -o conftest -g -O2 conftest.c 5 Warning(1028): getifaddrs_ is an undefined reference That's only a warning? Is there a way to force cc on QNX4 to *fail* if some symbol isn't found? If so, autoconf's AC_CHECK_FUNC macro should use that; perhaps there's a way for us to force it to do so in the configuration file. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 4:30 PM, Paul Thomas wrote: But, the behavior do not create executable if undefined symbols are present is not the same as having the linker fail, is it? What autoconf wants is to have an attempt to compile and link a program that refers to a particular symbol cause, on a system that doesn't have that symbol in the libraries being used, the linker to exit with a non-zero exit status; that's the sense in which the linker needs to fail in order for autoconf to work. Also, if there is a way of getting the linker to fail with undefined references, so that we could, in theory, have the configure script use an option to make it do so: This is problematic. Unfortunately, I do not know how, and the documentation does not make it obvious that this can be done for the linker. Oh, well - I guess that means that autoconf won't work on QNX (or QNX4, at least - it won't work on any of the QNX versions where the Watcom linker is being used). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
On Dec 16, 2004, at 4:44 PM, Guy Harris wrote: Oh, well - I guess that means that autoconf won't work on QNX (or QNX4, at least - it won't work on any of the QNX versions where the Watcom linker is being used). Or, more precisely, I guess that means that autoconf-generated configure scripts that use AC_CHECK_FUNC won't work on QNX Unfortunately, that includes scripts that test whether a particular function is available on the current platform, and the configuration script for libpcap is such a script. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
What autoconf wants is to have an attempt to compile and link a program that refers to a particular symbol cause, on a system that doesn't have that symbol in the libraries being used, the linker to exit with a non-zero exit status; that's the sense in which the linker needs to fail in order for autoconf to work. Also, if there is a way of getting the linker to fail with undefined references, so that we could, in theory, have the configure script use an option to make it do so: This is problematic. Unfortunately, I do not know how, and the documentation does not make it obvious that this can be done for the linker. Oh, well - I guess that means that autoconf won't work on QNX (or QNX4, at least - it won't work on any of the QNX versions where the Watcom linker is being used). The Watcom Linker issues three classes of messages; each message has a 4-digit number associated with it: - fatal messages start with the digit 3 - error messages start with the digit 2 - warning messages start with the digit 1 If a fatal error occurs, the linker terminates immediately. If an error occurs, the linker continues so that all possible errors are issued, and no executable is created. If a warning occurs, the linker continues (and doesn't prevent the creation of a proper executable). The documentation for the Watcom Linker does not say how a given warning or error can be promoted to fatal. :-( - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Unfortunately, it'll turn *all* warnings into errors; the only warnings I want turned into errors are the warnings for undefined references, as there might be other warnings that are harmless *and* difficult if not impossible to eliminate in a configure script. That's probably a warning from the linker - i.e., it's presumably produced after the object files have been created. Is there an option to get the linker to fail with undefined refeerences? The option UNDEFSOK defaults to OFF. When specified, it enables the linker to create the executable if undefined symbols are present. But, the behavior do not create executable if undefined symbols are present is not the same as having the linker fail, is it? There is an option to set the maximum error messages, but this doesn't include warning messages. When the limit is reached, the linker issues a fatal error and terminates. wlink OPTION MAXERRORS=n And is the linker part of the Watcom C compiler? No, it is separate, 'wlink'. Also, if there is a way of getting the linker to fail with undefined references, so that we could, in theory, have the configure script use an option to make it do so: This is problematic. Unfortunately, I do not know how, and the documentation does not make it obvious that this can be done for the linker. What compilers are used with QNX? There's probably a GCC port; is there any significant non-GCC compiler other than Watcom? /usr/local/lib/gcc-lib/i386-pc-qnx4/egcs-2.91.66 exists, but gcc does not. Not sure why. The Watcom compiler/linker is used exclusively. what does host_os get set to on QNX? host_os='qnx' - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Hello: I am trying to build libpcap for QNX 4.25, and am experiencing the following error: Unable to open 'ifaddrs.h' The configure script reports: checking ifaddrs.h usability... yes checking ifaddrs.h presence... no checking for ifaddrs.h... no What can I do about this? (The file does not exist.) For my next trick (nothing up my sleeve!!!) I will answer my own question. From the TCP/IP Library Reference / System Library Functions Manual NAME getifaddrs - get interface addresses SYNOPSIS #include sys/types.h #include sys/socket.h #include ifaddrs.h int getifaddrs(struct ifaddrs **ifap); The getifaddrs() function first appeared in BSDI BSD/OS. The function is supplied on OpenBSD since OpenBSD 2.7. H So now I must scarf this file from an OpenBSD distro so that I can continue and build libpcap 0.8.3 for QNX 4.25 ?? Egads, the slope gets more slippery. Paul Thomas - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Unable to open 'ifaddrs.h' The configure script reports: checking ifaddrs.h usability... yes checking ifaddrs.h presence... no checking for ifaddrs.h... no What can I do about this? (The file does not exist.) Okay, instead of being delerious, I will try to be helpful... There is a very clear dependency on ifaddrs.h. Am I right to say that it is needed to build libpcap? If not... Is there an alternate method to discover the interface addresses? (i.e. one that does not depend on ifaddrs.h) If so, can someone describe how to invoke an alternate method? Possibly replace fad-getad.c in the Makefile with a variant? If not, then it should be fairly straightforward (in the configure script?) to generate a warning message stating that libpcap cannot be built without this supporting file. Ideas? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap build error
Here is the relevant output, from config.log: configure:3348: checking ifaddrs.h usability configure:3361: cc -c -g -O2 conftest.c 5 configure(3393): Error! E1055: Unable to open 'strings.h' configure(3396): Error! E1055: Unable to open 'inttypes.h' configure(3405): Error! E1055: Unable to open 'ifaddrs.h' configure:3364: $? = 0 configure:3367: test -s conftest.o configure:3370: $? = 0 configure:3380: result: yes configure:3384: checking ifaddrs.h presence configure:3395: cc -E conftest.c configure(3407): Error! E1055: Unable to open 'ifaddrs.h' configure:3401: $? = 0 configure: failed program was: | #line 3387 configure | /* confdefs.h. */ | | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define inline inline | #define HAVE___ATTRIBUTE__ 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | #include ifaddrs.h configure:3420: result: no configure:3426: WARNING: ifaddrs.h: accepted by the compiler, rejected by the preprocessor! configure:3428: WARNING: ifaddrs.h: proceeding with the preprocessor's result configure:3456: checking for ifaddrs.h configure:3463: result: no - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
