From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Failure building collectd when autoconf has been updated to 2.72 Date: Sat, 23 Nov 2024 10:12:31 +0100 Message-ID: <137CF60C-0FA2-4715-85AB-FE314768B13A@ipfire.org> In-Reply-To: <8149d693-f931-42a3-b83e-7deb106fbc8f@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0554366240305104386==" List-Id: --===============0554366240305104386== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, Hmm, then let us maybe look at migrating collectd. It will be a pain, but it = seems that fixing the autoconf problem won=E2=80=99t be much easier. There is a migration script here: https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26= b034eec/contrib/migrate-4-5.px#L107-L108 Should we maybe start with building a new branch with the latest version of c= ollectd 5 and simply check if a newly installed system is still working? I do= n=E2=80=99t think there will be that many changes required. Would you be up f= or giving that a go? If we can then run the migration script on existing systems we might almost b= e there=E2=80=A6 -Michael > On 22 Nov 2024, at 18:01, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 20/11/2024 19:25, Michael Tremer wrote: >> Let=E2=80=99s maybe try to avoid running autoconf altogether. >> There might be a small chance because only two patches change configure.ac= . There are others that change Makefile.in, so this might not work at all. Le= t=E2=80=99s see=E2=80=A6 >> Could you please remove the patches in src/patches/collectd with number 12= and 13? Then remove the autoreconf commands from lfs/collectd. >> Things should hopefully still apply and after the first run of configure, = make should not try to run autoconf again. Not sure but worth a try. >=20 > I removed the two patches and also removed the two autoreconf commands, lea= ving the autoupdate command in place. >=20 > Unfortunately it failed to build and had the following error message >=20 > aclocal.m4:16: warning: this file was generated for autoconf 2.67. > You have another version of autoconf. It may work, but is not guaranteed t= o. > If you have problems, you may need to regenerate the build system entirely. > To do so, use the procedure documented by the package, typically `autorecon= f'. > configure.in:533: error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O > configure.in:533: the top level > autom4te: error: /tools_x86_64/bin/m4 failed with exit status: 1 > make[1]: *** [Makefile:375: configure] Error 1 > make[1]: Leaving directory '/usr/src/collectd-4.10.9' > make: *** [collectd:117: /usr/src/log/collectd-4.10.9] Error 2 >=20 >> I can=E2=80=99t remember what has stopped us from moving with upstream apa= rt from the RRD file format. If this all doesn=E2=80=99t work, maybe we shoul= d look at this all again and see if we can=E2=80=99t migrate to the latest up= stream version again. >=20 > As far as I can remember it was mentioned that the issue was the changed fo= rmat and RRD being used in so many places making the update require changes i= n so many places in IPFire-2.x >=20 > Regards, >=20 > Adolf. >=20 >> Best, >> -Michael >>> On 19 Nov 2024, at 13:55, Adolf Belka wrote: >>> =EF=BB=BFHi Michael, >>>=20 >>> Also reran the collectd autoreconf with the autoconf-2.71 and in that cas= e the line has yes:) so something about the autoconf-2.72 is causing that one= yes: in the configure file to be missing the ) . There are something like 20= of those yes: entries and with the autoconf-2.72 only the one I show below i= s the one with a missing ), all the rest have a yes:) entry. >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>> On 19/11/2024 14:43, Adolf Belka wrote: >>>> Hi Michael, >>>>=20 >>>> I obtained the configure created by the autoreconf etc and I have found = the error. Here is the affected line 18710 >>>>=20 >>>>=20 >>>> 18706 if test "x$ac_ct_CC" =3D x; then >>>> 18707 CC=3D"" >>>> 18708 else >>>> 18709 case $cross_compiling:$ac_tool_warned in >>>> 18710 yes: >>>> 18711 >>>> 18712 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: using cross= tools not prefixed with host triplet" >&5 >>>> 18713 printf "%s\n" "$as_me: WARNING: using cross tools not prefixed wit= h host triplet" >&2;} >>>> 18714 ac_tool_warned=3Dyes ;; >>>> 18715 esac >>>> 18716 CC=3D$ac_ct_CC >>>> 18717 fi >>>> 18718 else >>>> 18719 CC=3D"$ac_cv_prog_CC" >>>> 18720 fi >>>>=20 >>>> That line should be yes:) so it is missing a right bracket. Not sure if = you can figure where and why that is occurring but presumably a patch can be = written to be applied after the autoreconf etc and before the ./configure com= mand >>>>=20 >>>> Regards, >>>> Adolf. >>>>=20 >>>>=20 >>>>> On 19/11/2024 12:41, Michael Tremer wrote: >>>>> Hello Adolf, >>>>> In the build script we are running autoreconf which will regenerate the= configure script: >>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dlfs/collectd;h= =3Dd1d4ea721386803c31599315de956373417c2dcf;hb=3DHEAD#l119 >>>>> Is there any output of that command? There should be some warnings whic= h might help us to find out what we need to change. >>>>>> On 13 Nov 2024, at 10:30, Adolf Belka wrote: >>>>>> Hi All, >>>>>> I did an update run with autoconf taking it from 2.71 to 2.72 >>>>>> autoconf built without any problems, however collectd then failed for = a syntax error in the configure file. >>>>>> Confirmed that this was due to autoconf by changing the versions back = and forward and the problem went away and then came back again. >>>>>> The collectd build error message is >>>>>> 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 >>>>>> The section around line 18710 in the configure file is >>>>>> 18707 do : >>>>>> 18708 as_ac_Header=3D`$as_echo "ac_cv_header_$ac_header" | $as_t= r_sh` >>>>>> 18709 ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_H= eader" "$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 >>>>>> However there are 15 occurrences of the exact same text as line 18710 = in the configure file so I am not convinced if that line is the root cause fo= r the syntax error but some other earlier error that causes a knock-on effect. >>>>>> However, my knowledge of the coding syntax is definitely not enough to= figure out what needs to be fixed/changed. >>>>>> As collectd is a very old version it is likely that some structural co= ding or syntax was fine in the past but now with the change from autoconf-2.7= 1 to 2.72 it is no longer allowed, or is flagged up when in the past it was j= ust ignored. >>>>>> There are quite a few changes in autoconf-2.72 with some being marked = as backwards compatibilities. All of them except one say that existing config= ure scripts will continue working. The one that doesn't mention that is the f= ollowing change:- >>>>>> 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. >>>>>> 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), which 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 feat= ure of >>>>>> C 1989. >>>>>> However I am unable to figure out from this if the problem I am experi= encing is related to this or not. I would not have thought so as I don't beli= eve we are using a pre-1989 C compiler. >>>>>> Any ideas from anyone on how to fix this issue? >>>>>> There is nothing critical from a security or other vulnerability aspec= t in autoconf-2.72 but it would be nice to figure this out before we get to a= stage where it has to be made to work. >>>>>> Regards, >>>>>> Adolf. >=20 --===============0554366240305104386==--