--- Begin Message ---
On Fri, 27 Jan 2023 01:40:48 -0800
Guy Harris <ghar...@sonic.net> wrote:
> On Jan 22, 2023, at 9:59 AM, Denis Ovsienko via tcpdump-workers
> <tcpdump-workers@lists.tcpdump.org> wrote:
>
> > I have also removed AC_LBL_C_INLINE and a conditional substitute for
> > Tru64 pfopen() from tcpslice. Interestingly, tcpslice and tcpdump,
> > which don't call pfopen(), used to have this substitute, and
> > libpcap, which does call pfopen(), does not have it.
>
> That dates back to tcpdump 3.4. I don't know why they decided to
> compile pfopen() into tcpdump and tcpdslice if it's not in a system
> library, rather than compiling it into libpcap if it's not in a
> system library. Perhaps they wanted to be able to build versions of
> libpcap that would work both on Tru64 UNIX versions in which pfopen()
> is in a system library and versions in which it's not and all you
> have is pfopen.c source code under /usr/examples.
>
> I don't know what older versions those might be, and I suspect we
> have little if any reason to continue to make it possible to build
> tcpdump or tcpslice on those older versions - it looks as if Tru64
> UNIX 4.x and 5.x have pfopen() in system libraries; according to
>
> https://en.wikipedia.org/wiki/Tru64_UNIX
>
> 4.0A through 4.0F all date back to the previous millennium.
Thank you for confirming.
> > In tcpdump it is a bit more entrenched, so I did not touch it yet.
>
> It looks as if you removed the pfopen() stuff from tcpdump's
> configure script in 43670fb635503e69cdbf8055134a0befb94d2e15.
Yes, the Autoconf problem/solution space has been getting smaller. On
one hand, there is build logic that has been obsolete for a while, and
on the other there is logic that is very much in the loop, but has not
been converted to the 2.69 dialect yet. Quite a few more rounds of
improvements remain to be done in both departments.
Specifically, losing Ultrix props should be among the safest things to
do.
> The AC_LBL_C_INLINE stuff is still there, but doesn't look *that*
> entrenched; are there any compilers that we need to support and that
> *don't* support C99 inline? If not, we could just remove the call
> from configure.ac and the definition from aclocal.m4.
In 2002 in commit b1263c6 you wrote it was some HP C compiler that
Autoconf 2.13 could not drive. I have never seen HP-UX in the wild, but
assuming the amount of improvement made in Autoconf during the
subsequent 10 years (Autoconf 2.69 is from 2012) and the amount of
improvement made in HP-UX (which had the most recent release in 2022),
to me it would make the most sense to say the problem AC_LBL_C_INLINE
solved (HP C specifics) no longer exists unless proven otherwise, and
AC_LBL_C_INLINE should be removed with a good change log entry.
I do not understand yet if AC_LBL_C_INLINE could just disappear safely
altogether instead of being replaced with AC_C_INLINE.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
