Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- On Aug 15, 2022, at 1:37 PM, Christian wrote: > configure:6075: checking for pcap_loop > configure:6075: gcc -o conftest -g -O2 conftest.c -L/usr/local/lib > -Wl,-rpath,/usr/local/lib -lpcap >&5 > /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to > `scsimon_create' > /usr/bin/ld: /usr/local/lib/libpcap.so: undefined reference to > `scsimon_findalldevs' Has the pcap.c in the libpcap that was built and installed in /usr/local/lib been modified to add a pcap module "scsimon", in addition to your "kpnode" module? If so, is there a pcap-scsimon.c, or whatever, that defines them, and was it also added to Makefile.in when the library was built?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- Am 15.08.22 um 20:09 schrieb Guy Harris: What are the contents of config.log? Ohhh f**. Ok sorry it's moday afternoon here it comes: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by tcpdump configure 5.0.0-PRE-GIT, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = debian0 uname -m = x86_64 uname -r = 5.18.0-3-amd64 uname -s = Linux uname -v = #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/local/games PATH: /usr/games ## --- ## ## Core tests. ## ## --- ## configure:2463: checking build system type configure:2477: result: x86_64-pc-linux-gnu configure:2497: checking host system type configure:2510: result: x86_64-pc-linux-gnu configure:2655: checking for gcc configure:2671: found /usr/bin/gcc configure:2682: result: gcc configure:2911: checking for C compiler version configure:2920: gcc --version >&5 gcc (Debian 12.1.0-8) 12.1.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2931: $? = 0 configure:2920: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.0 (Debian 12.1.0-8) ... rest of stderr output deleted ... configure:2931: $? = 0 configure:2920: gcc -V >&5 gcc: error: unrecognized command-line option '-V' gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2920: gcc -qversion >&5 gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:2931: $? = 1 configure:2951: checking whether the C compiler works configure:2973: gcc conftest.c >&5 configure:2977: $? = 0 configure:3025: result: yes configure:3028: checking for C compiler default output file name configure:3030: result: a.out configure:3036: checking for suffix of executables configure:3043: gcc -o conftest conftest.c >&5 configure:3047: $? = 0 configure:3069: result: configure:3091: checking whether we are cross compiling configure:3099: gcc -o conftest conftest.c >&5 configure:3103: $? = 0 configure:3110: ./conftest configure:3114: $? = 0 configure:3129: result: no configure:3134: checking for suffix of object files configure:3156: gcc -c conftest.c >&5 configure:3160: $? = 0 configure:3181: result: o configure:3185: checking whether we are using the GNU C compiler configure:3204: gcc -c conftest.c >&5 configure:3204: $? = 0 configure:3213: result: yes configure:3222: checking whether gcc accepts -g configure:3242: gcc -c -g conftest.c >&5 configure:3242: $? = 0 configure:3283: result: yes configure:3300: checking for gcc option to accept ISO C89 configure:3363: gcc -c -g -O2 conftest.c >&5 configure:3363: $? = 0 configure:3376: result: none needed configure:3396: checking for gcc option to accept ISO C99 configure:3545: gcc -c -g -O2 conftest.c >&5 configure:3545: $? = 0 configure:3558: result: none needed configure:371
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- What are the contents of config.log? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message ---
Then I opened the tcpdump.zip archive
(.zip? Not .tar.gz? The current releases from
https://www.tcpdump.org/index.html#latest-releases
are provided in .tar.gz form, as are all the other release in
https://www.tcpdump.org/release/
Gzipped tarballs are probably easier to extract on a UN*X, as they're likely to have either a
version of tar that reads gzipped files or have gzcat and tar; to unpack a zip archive requires a
command such as unzip or a GUI tool that unpacks zip archives. Perhaps you mean ".zip
archive" in a metaphorical sense of "some form of archive"? Or is this a ZIP
archive provided by somebody other than tcpdump.org?)
Okay I was not quite consequent, got the sources of libpcap from git but
tcpdump from the zip archive of github. But today I tried it again with
git. And this time I didn't put it into the libpcap directory but into
the parent directory, so that they have the same parent. But the result
remains the same.
No, they're not attached. Either you forgot to attach them or some mail
software stripped the attachments. Michael/Denis/François - do we strip
attachments at any point before sending messages to the list?
Okay bad idea of mine, attached files are hard to comment in a list anyway.
Now I paste it here:
pcap-kpnode.c
#include
#include "pcap-int.h"
#include
#include
#include
#define LINUX_KPNODE_DEV "/dev/kpnode0"
#define KPNODE_IFACE "kpnode"
#define KPNODE_LINE_LEN 4096
struct pcap_kpnode {
};
/* facility to add an USB device to the device list*/
static int
kpnode_dev_add(pcap_if_list_t *devlistp, int n, char *err_str)
{
char dev_name[10];
char dev_descr[30];
snprintf(dev_name, 10, KPNODE_IFACE"%d", n);
/*
* XXX - is there any notion of "up" and "running"?
*/
/*
* As this refers to all buses, there's no notion of
* "connected" vs. "disconnected", as that's a property
* that would apply to a particular USB interface.
*/
if (add_dev(devlistp, dev_name,
PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE,
"Open kpnode interface ", err_str) == NULL)
return -1;
return 0;
}
int
kpnode_findalldevs(pcap_if_list_t *devlistp, char *err_str)
{
char kpnode_dev[PATH_MAX];
char *kpnode_prefix;
//size_t usb_mon_prefix_len;
//struct dirent* data;
// int ret = 0;
//DIR* dir;
//int n;
//char* name;
/*
* We require 2.6.27 or later kernels, so we have binary-mode support.
* What do the device names look like?
* Split LINUX_USB_MON_DEV into a directory that we'll
* scan and a file name prefix that we'll check for.
*/
pcap_strlcpy(kpnode_dev, LINUX_KPNODE_DEV, sizeof kpnode_dev);
kpnode_prefix = strrchr(kpnode_dev, '0');
if (kpnode_prefix == NULL) {
/*
* This "shouldn't happen". Just give up if it
* does.
*/
return 0;
}
*kpnode_prefix++ = '\0';
//usb_mon_prefix_len = strlen(usb_mon_prefix);
/*
* Open the directory and scan it.
*/
// dir = opendir(usb_mon_dir);
// if (dir != NULL) {
// while ((ret == 0) && ((data = readdir(dir)) != 0)) {
// name = data->d_name;
//
// /*
// * Is this a usbmon device?
// */
// if (strncmp(name, usb_mon_prefix, usb_mon_prefix_len) != 0)
// continue; /* no */
//
// /*
// * What's the device number?
// */
// if (sscanf(&name[usb_mon_prefix_len], "%d", &n) == 0)
// continue; /* failed */
//
// ret = kpnode_dev_add(devlistp, n, err_str);
// }
//
// closedir(dir);
kpnode_dev_add(devlistp, 0, err_str);
return 0;
} /* kpnode_findalldevs */
pcap_t *
kpnode_create(const char *device, char *ebuf, int *is_ours)
{
const char *cp;
char *cpend;
long devnum;
pcap_t *p;
/* Does this look like a USB monitoring device? */
cp = strrchr(device, '/');
if (cp == NULL)
cp = device;
/* Does it begin with USB_IFACE? */
if (strncmp(cp, KPNODE_IFACE, sizeof KPNODE_IFACE - 1) != 0) {
/* Nope, doesn't begin with USB_IFACE */
*is_ours = 0;
return NULL;
}
/* Yes - is USB_IFACE followed by a number? */
cp += sizeof KPNODE_IFACE - 1;
devnum = strtol(cp, &cpend, 10);
if (cpend == cp || *cpend != '\0') {
/* Not followed by a number. */
*is_ours = 0;
return NULL;
}
if (devnum < 0) {
/* Followed by a non-valid number. */
*is_ours = 0;
return NULL;
}
/* OK, it's probably ours. */
*is_ours = 1;
p = PCAP_CREATE_COMMON(ebuf, struct pcap_kpnode);
if (p == NULL)
return (NULL);
//p->activate_op = usb_activate;
return (p);
} /* kpnode_create */
and pcap-kpnode.h
int kpnode_findalldevs(pcap_if_list_t *devlistp, char *err_str);
pcap_t *kpnode_create(const ch
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- On Aug 15, 2022, at 12:50 AM, Denis Ovsienko via tcpdump-workers wrote: > On Sun, 14 Aug 2022 11:49:57 -0700 > Guy Harris via tcpdump-workers > wrote: > >> Or is this a ZIP archive provided by somebody other than tcpdump.org? > > github.com -> code -> download ZIP. I vaguely remember there was a > "download tar.gz" there as well, but not anymore. Anyway, git clone is > better order of magnitudes, in that it allows to tell which commit the > working copy is at. So they're building from the current main branch, rather than from a release tarball (or from the source used to build the versions of libpcap and tcpdump in the OS they're using)? If so, then, yes, they should use git clone, not only for the reason you mention, but because it's not a snapshot, it's a repository, so it can be updated to the current state of the main branch.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] configure script problem while working on extention
--- Begin Message --- On Sun, 14 Aug 2022 11:49:57 -0700 Guy Harris via tcpdump-workers wrote: > Or is this a ZIP archive provided by somebody other than tcpdump.org? github.com -> code -> download ZIP. I vaguely remember there was a "download tar.gz" there as well, but not anymore. Anyway, git clone is better order of magnitudes, in that it allows to tell which commit the working copy is at. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
