Romain Francoise wrote:
It's not too late to release 0.9.2 with these API changes and encourage
people not to use 0.9.1...
...assuming that we do it before some {Linux distribution, flavor of
BSD, etc.} puts 0.9.1 into a release that lasts for N months before the
next release, with 0.9.2,
-BEGIN PGP SIGNED MESSAGE-
Romain == Romain Francoise [EMAIL PROTECTED] writes:
Unfortunately, that happened after the 0.9/3.9 release, so, for
better or worse, we're stuck with the old names; I've backed out
the aforementioned change.
Romain It's not too late to
Michael Richardson wrote:
If it happens this week, I'm fine with that.
OK, I'll check those changes in again this week.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
* Guy Harris:
Florian Weimer wrote:
* Guy Harris:
note that the *same* executable image can run with *different*
libpcap library versions, if it's built with a shared version of
libpcap, so a compile-time test can't always give the right answer.
Is this really the case? I thought that most
Florian Weimer wrote:
But it isn't, the behavior has changed. Otherwise I wouldn't have
this trouble. 8-)
The behavior changed, but that's a bug fix. Not all OS vendors consider
a bug fix to be something that breaks binary compatibility to an extent
that the library's *major* version
Guy Harris [EMAIL PROTECTED] writes:
If the interface doesn't change (so that the new version of the library
is binary backwards-compatible with the old version, even if it's not
forwards-compatible, i.e. new APIs were added or new capabilities were
added to existing APIs), the version
| API addition: typedef direction_t is new
| is now defined at /usr/include/pcap.h:123:
| typedef enum
| {
| D_INOUT = 0,
| D_IN = 1,
| D_OUT = 2,
| } direction_t;
shouldn't that be pcap_direction_t? otherwise i can imagine some
namespace collision occuring...
-dean
-
On Jul 5, 2005, at 3:03 PM, Guy Harris wrote:
Yeah, probably. I've checked in a change to do that - and to
rename the D_ values in it to PCAP_D_ as well.
Unfortunately, that happened after the 0.9/3.9 release, so, for
better or worse, we're stuck with
the old names; I've backed out the
What's the best way to detect libpcap 0.9 and later versions? In my
application, I've got a workaround for this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306811
Apparently, this bug has been fixed in versions after 0.8, and
therefore, I should disable the workaround. How
* Guy Harris:
Florian Weimer wrote:
What's the best way to detect libpcap 0.9 and later versions? In my
application, I've got a workaround for this Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306811
That bug is not unique to Debian.
Yes, I known, I just wanted to
Florian Weimer wrote:
* Guy Harris:
note that the *same* executable image can run with *different*
libpcap library versions, if it's built with a shared version of
libpcap, so a compile-time test can't always give the right answer.
Is this really the case? I thought that most distributions
11 matches
Mail list logo
