At 12:15 PM -0700 2002/05/01, Guy Harris wrote:
> So, whilst the configure script will not *explicitly* define it as
> anything other than an unsigned long, if it's already defined by the OS
> - whether as an "unsigned int", or as an "unsigned long", or as
> something else - it will not define it at all, so the OS's definition
> will be used, and that definition might be "unsigned int".
Oh. Okay. I guess I'm just demonstrating my ignorance again.
Thanks for the clarification. It is interesting to learn more
about how some of these kinds of things are handled, and what kind of
sometimes convoluted path things sometimes tend to take.
> It would probably be best if the xprobe configure script used "unsigned
> int" rather than "unsigned long"; "unsigned int" won't work on PDP-11s
> or Zilog Z8000-based machines or some very old 68000-based machines or
> pre-80386 PCs or other 16-bit-"int" platforms, but "unsigned long" won't
> work on Alphas or IA-64s in native mode or 64-bit
> {MIPS,SPARC,POWER/PowerPC,PA-RISC,...} machines, and the first set are
> old platforms on which I suspect xprobe might not work anyway while the
> latter set are new machines, so I'd say it'd be better to cater to those
> machines rather than the older machines. (I suspect there are
> OSes/compilers for those newer machines that don't define "uint32_t".)
Actually, I would submit that the configure script (I'm pretty
sure it's just a very old gnu autoconf script) should be more
intelligent and automatically detect the natural word length of the
CPU it's running on, and then for types like uint32_t, it should then
select the "shortest" type that would fit the necessary bit length.
>> However, note that there is no system-supplied pcap.h.
>
> It's often the case that a library that's supplied as a dynamic library
> will include two packages:
>
> 1) a run-time package, which is installed for the benefit of
> programs that *use* the library, which contains only what you
> need to run those programs, i.e. the dynamic library and any
> files it requires;
>
> 2) a developer's package, which is for use when you're
> *compiling* programs that use the library, and which would
> contain header files and perhaps non-shared libraries and the
> like.
For MacOS X, the Developer's Tools are available on a separate CD
in the commercial shrink-wrap package for MacOS X (note that MacOS X
Server is a different product), and I actually do have the complete
developer's toolkit installed on this machine. I'm guessing that
this is a feature that either got accidentally omitted, or perhaps
they made a conscious decision to leave out certain header files.
But then why they'd ship a broken libpcap implementation is something
that just completely escapes me.
> There isn't one on your machine, at least. I suspect there may be some
> developer's package that includes it.
I've got the developer's package installed. If I didn't, then I
wouldn't have gcc.
> I've no idea why
>
> % gcc iflist.c -o iflist -lpcap
>
> managed to find the one in "/usr/local/include"; perhaps GCC defaults to
> looking there as well, or perhaps you have some environment variable set
> causing it to search there.
IIRC, in at least some implementations, gcc does default to
looking in both /usr/lib and /usr/local/lib, as well as /usr/include
and /usr/local/include. Certainly this has been the kind of
behaviour I have come to expect from gcc in all my previous
encounters with it.
> If you put "-lpcap" *after*" "iflist.c", it will be linked *after*
> "iflist.o", so that the libpcap functions referred to by "iflist.c" will
> have been referred to, and the files in the libpcap library that define
> those functions will be linked in, and those functions will be defined.
Right, which is what we want -- I think.
>> However, the resulting program still doesn't work:
>>
>> % ./iflist
>> Error in pcap_lookupdev: no suitable device found
>> Preferred device is on network: 0.0.0.0/0.0.0.0
>
> Well, that's the same problem you saw with the other programs.
Of course, it turns out that another problem was the root uid issue.
> Well, that's annoying, but I guess that's another Apple "improvement".
> Linkers on *other* flavors of UNIX tend to use the first library found
> in the library search path *even if it happens to be an archive
> library*, on the grounds that the user told them to do that.
In that case, there would seem to be no way we could over-ride a
broken libpcap.dylib library, without moving it aside and generating
our own compatibly formatted dynamic library, and then store that in
/usr/lib. We need to provide functionality for future programs
(which could be statically linked), but we also need to provide
corrected functionality for existing programs (which would depend on
the dynamic library).
--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
