Re: AC_LBL_FIXINCLUDES does not make it into configure

[Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Fri, 27 Jan 2023 12:53:28 +0000
>
> On Fri, 27 Jan 2023 01:40:48 -0800
> Guy Harris <gharris () 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