From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Failure building collectd when autoconf has been updated to 2.72
Date: Tue, 19 Nov 2024 11:41:16 +0000
Message-ID: <7FF4003D-1ECC-4A48-8C4E-43B085EF0BD3@ipfire.org>
In-Reply-To: <61df5b92-8aa1-4972-92bc-b3040e203412@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1530469972182218019=="
List-Id: <development.lists.ipfire.org>

--===============1530469972182218019==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Adolf,

In the build script we are running autoreconf which will regenerate the confi=
gure script:

  https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dlfs/collectd;h=3Dd1=
d4ea721386803c31599315de956373417c2dcf;hb=3DHEAD#l119

Is there any output of that command? There should be some warnings which migh=
t help us to find out what we need to change.

> On 13 Nov 2024, at 10:30, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>=20
> Hi All,
>=20
> I did an update run with autoconf taking it from 2.71 to 2.72
>=20
> autoconf built without any problems, however collectd then failed for a syn=
tax error in the configure file.
>=20
> Confirmed that this was due to autoconf by changing the versions back and f=
orward and the problem went away and then came back again.
>=20
> The collectd build error message is
>=20
> checking for size_t... yes
> checking for uid_t... yes
> checking for gid_t... yes
> ./configure: line 18710: syntax error near unexpected token `newline'
> ./configure: line 18710: `yes:'
> make: *** [collectd:120: /usr/src/log/collectd-4.10.9] Error 2
>=20
> The section around line 18710 in the configure file is
>=20
> 18707    do :
> 18708       as_ac_Header=3D`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> 18709    ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header=
" "$ac_includes_default"
> 18710    if eval test \"x\$"$as_ac_Header"\" =3D x"yes"; then :

There is an extra : here which is probably what causes the syntax error.

> 18711      cat >>confdefs.h <<_ACEOF
> 18712    #define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
> 18713    _ACEOF
> 18714
> 18715    else
> 18716      with_libiptc=3D"no (header file missing)"
> 18717    fi
>=20
> However there are 15 occurrences of the exact same text as line 18710 in th=
e configure file so I am not convinced if that line is the root cause for the=
 syntax error but some other earlier error that causes a knock-on effect.
>=20
> However, my knowledge of the coding syntax is definitely not enough to figu=
re out what needs to be fixed/changed.
>=20
> As collectd is a very old version it is likely that some structural coding =
or syntax was fine in the past but now with the change from autoconf-2.71 to =
2.72 it is no longer allowed, or is flagged up when in the past it was just i=
gnored.
>=20
> There are quite a few changes in autoconf-2.72 with some being marked as ba=
ckwards compatibilities. All of them except one say that existing configure s=
cripts will continue working. The one that doesn't mention that is the follow=
ing change:-
>=20
>   Configure scripts no longer support pre-1989 C compilers.
>   Specifically, compilers that *only* implement the original =E2=80=9CK&R=
=E2=80=9D
>   function definition syntax, and not the newer =E2=80=9Cprototyped=E2=80=
=9D syntax,
>   will not be able to parse the test programs now emitted by
>   AC_CHECK_FUNC, AC_LANG_CALL, and similar macros.  AC_PROG_CC still
>   accepts such compilers, but this may change in the near future.
>=20
>   This change was necessary in order to support the upcoming 2024
>   edition of the C standard (often referred to as =E2=80=9CC23=E2=80=9D), w=
hich will
>   officially remove the function declaration syntax used by
>   AC_CHECK_FUNC in Autoconf 2.71 and earlier.  We feel that support
>   for compilers that support only C 2024 is more useful, nowadays,
>   than support for compilers that don=E2=80=99t implement a core feature of
>   C 1989.
>=20
> However I am unable to figure out from this if the problem I am experiencin=
g is related to this or not. I would not have thought so as I don't believe w=
e are using a pre-1989 C compiler.
>=20
> Any ideas from anyone on how to fix this issue?
>=20
> There is nothing critical from a security or other vulnerability aspect in =
autoconf-2.72 but it would be nice to figure this out before we get to a stag=
e where it has to be made to work.
>=20
>=20
> Regards,
>=20
> Adolf.
>=20


--===============1530469972182218019==--