Builder libpcap-solaris10-sparc Build #3157

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-libpcap-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 20 secs )
   1. stdio
2. shell Set developer mode ( 0 secs )
   1. stdio
3. shell_1 './autogen.sh' ( 45 secs )
   1. stdio
4. shell_2 './configure' ( 1 mins, 47 secs )
   1. stdio
   2. config.log
5. shell_3 'gmake' ( 1 mins, 34 secs )
   1. stdio
6. shell_4 'gmake check' ( 17 mins, 23 secs )
   1. stdio
7. shell_5 'rm -rf ...' ( 0 secs )
   1. stdio
8. shell_6 'gmake install ...' ( 5 secs )
   1. stdio
9. trigger triggered trigger-tcpdump-solaris10-sparc ( 19 mins, 52 secs )
   1. - no logs -
   2. tcpdump-solaris10-sparc #6043

Build Properties:

Forced Build Properties:

Responsible Users:

1. Guy Harris

   gharrisohnoyoudont@sonic.net

Timing:

All Changes:

:

1. Change #241248

   Category	libpcap
   Changed by	Guy Harris <gharrisohnoyoudont@sonic.net>
   Changed at	Wed 30 Jul 2025 04:29:47
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	6bdc8bdd5a81e99571a4293c67d6a8c87cd6ff94

   Comments

   dlpi: some restructuring.
   Have a common routine to handle the "that interface doesn't have a DLPI
   device" error; it takes care of "device name too long to be an
   interface", "we have no DLPI devices because we're in a shared-IP
   non-global zone", and "we have no DLPI device for that interface because
   it's probably not a DLPI interface" (as in "the loopback device on
   Solaris 10 and before").
   
   On HP-UX, where there's just one /dev/dlpi device, if we don't have
   permission to open that device, check whether the interface exists and,
   if not, report "no such interface" - see
   https://github.com/the-tcpdump-group/libpcap/issues/1538.
   
   On Solaris with libdlpi, distinguish between "that link name is
   invalid", in which case we know for certain that the interface doesn't
   exist, and "no such link", in which case we use the common routine
   mentioned above to find out why.
   
   Remove "libpcap:" from messages reporting errors from libdlpi; none of
   our other messages announce that they come from libpcap.
   
   Expand and clarify comments while we're at it.

   Changed files

   • dlpisubs.c
   • dlpisubs.h
   • pcap-dlpi.c
   • pcap-libdlpi.c