Hi -
I downloaded the 2005.01.14 bits and went to compile them on HP-UX 11iv1 (11.11) and HP-UX 11iv2u2 (11.23 pi - PA and IPF, but in this case on IPF).
On 11iv2u2 for libpcap, folks will see a warning from the compiler about a redeclaration of IFF_PRIORITY. This _appears_ to stem from /usr/include/net/if.h and if6.h having an IFF_PRIORITY macro, and if.h including if6.h...
The HP-UX transport team said:
This is a known problem in 11.23PI, with the CR# JAGaf46044. The suggested workaround is to comment out the definition of IFF_PRIORITY in net/if.h. We've also provided the edited version of this file to GSE for distribution to affected customers until a patch is released.
ld: Unsatisfied symbol "EXTRACT_64BITS" in file print-nfs.o
It looks like there are indeed two definitions for EXTRACT_LE_64BITS in extract.h, with one being condtional, and the other being unconditional, so when the conditions are met, one gets two definitions. Interestingly enough, and perhaps this is the root of most of it - the condtional EXTRACT_LE_64BITS is after an EXTRACT_32BITS and EXTRACT_16BITS - I wonder if that "_LE_" is a typo on line 76? That might explain why there is then the no EXTRACT_64BITS error later in ld.
and indeed, removing the _LE_ from line 76 seems to result in happiness and joy and a working tcpdump (32-bit) on IA64/IPF 11iv2u2.
I went ahead and tried a 64-bit compile on 11iv2u2. Gencode compilation emits this warning:
cc -O +DD64 -I. -I/usr/local/include -DHAVE_CONFIG_H -D_U_="" -c ./gencode.c
Warning 863: "./gencode.c", line 235 # Result of operator << is widened from
int to unsigned long.
size = CHUNK0SIZE << k;
^^^^^^^^^^^^^^^
which is this code:
static void *
newchunk(n)
u_int n;
{
struct chunk *cp;
int k;
size_t size;#ifndef __NetBSD__
/* XXX Round up to nearest long. */
n = (n + sizeof(long) - 1) & ~(sizeof(long) - 1);
#else
/* XXX Round up to structure boundary. */
n = ALIGN(n);
#endif cp = &chunks[cur_chunk];
if (n > cp->n_left) {
++cp, k = ++cur_chunk;
if (k >= NCHUNKS)
bpf_error("out of memory");
size = CHUNK0SIZE << k;
cp->m = (void *)malloc(size);
if (cp->m == NULL)
bpf_error("out of memory");
memset((char *)cp->m, 0, size);
cp->n_left = size;
if (n > size)
bpf_error("out of memory");
}
cp->n_left -= n;
return (void *)((char *)cp->m + cp->n_left);
}IIRC in LP64, size_t is 64 bits, and earlier in the file we have:
#define CHUNK0SIZE 1024
which I suspect the compiler treats as an integer constant rather than a long constant. If I change the define to:
#define CHUNK0SIZE 1024L
the warning goes away, and the compiler still seems to be happy when doing a 32-bit compilation.
There seems to be a similar issue here:
cc -O +DD64 -DHAVE_CONFIG_H -I./missing -D_U_="" -I. -I./../libpcap -I/usr/local/include -I./missing -c ./print-icmp6.c
Warning 863: "./print-icmp6.c", line 594 # Result of operator << is widened
from int to long.
if (cp + (op->nd_opt_len << 3) > ep)
^^^^^^^^^^^^^^^^^^^
Warning 863: "./print-icmp6.c", line 715 # Result of operator << is widened
from int to long.
cp += op->nd_opt_len << 3;
^^^^^^^^^^^^^^^^^^^
In this case we have:
static void
icmp6_opt_print(const u_char *bp, int resid)
{
const struct nd_opt_hdr *op;
...
const u_char *cp, *ep;and of course a u_char * in LP64 is 64 bits.
The corresponding definition of nd_opt_hdr is:
struct nd_opt_hdr { /* Neighbor discovery option header */
u_int8_t nd_opt_type;
u_int8_t nd_opt_len;
/* followed by option specific data*/
};(from icmp6.h) and since that is defined by the standard I cannot change that to make the compiler happy, but perhaps casting it would be OK. I've not tried that yet myself - the only thing that would worry me is if the "sign" bit of the nd_opt_len were set - the compiler talking about things being widened from int to long makes me worry about sign bits.
However, a very brief test of tcpdump seems to imply it is OK as is (with the warning).
I tried putting some (unsigned long) casts in from of "op->nd_opt_len" and that seems to have made the compiler happy. That version also seems ok on a very quick test (although I doubt it saw any ICMP6 datagrams...)
rick jones - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
