Failure building collectd when autoconf has been updated to 2.72

Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

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=`$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"\" = x"yes"; then :
18711      cat >>confdefs.h <<_ACEOF
18712    #define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
18713    _ACEOF
18714
18715    else
18716      with_libiptc="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-

   Configure scripts no longer support pre-1989 C compilers.
   Specifically, compilers that *only* implement the original “K&R”
   function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
   C 1989.

However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.

Re: Failure building collectd when autoconf has been updated to 2.72

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3898 bytes --]

Hello Adolf,

In the build script we are running autoreconf which will regenerate the configure script:

  https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119

Is there any output of that command? There should be some warnings which might 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:
> 
> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
> 
>   Configure scripts no longer support pre-1989 C compilers.
>   Specifically, compilers that *only* implement the original “K&R”
>   function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>   C 1989.
> 
> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
> 

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 33500 bytes --]

Hi Michael,

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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
Ah yes, so when I have been looking at the configure script from the source tarball I was more than likely looking at a line number with different code in it than was actually used.

I should probably try and run the collectd patching and autoreconf and after that look at the configure script and see what is at the problem line number.
> 
> Is there any output of that command? There should be some warnings which might help us to find out what we need to change.
There is quite a bit and a lot of warnings about variables that are obsolete but i can't tell what might be a problem. Having the correct configure script to look at the actual command at the mentioned line number is probably a good first step.

Here is the log output for the autoupdate, autoreconf and autoreconf in libltdl after all the patches have been applied. Maybe you can see something that doesn't look right. I will try and get the actual configure file that is created and see what is at line 18710 in that file.

cd /usr/src/collectd-4.10.9 && autoupdate -v configure.in
autoupdate: running: echo dumpdef | /tools_x86_64/bin/m4 2>/tmp/auCniUF5/m4.defs >/dev/null
autom4te: the trace request object is:
autom4te: $VAR1 = bless( [
autom4te:                  '0',
autom4te:                  0,
autom4te:                  [
autom4te:                    '/usr/share/autoconf'
autom4te:                  ],
autom4te:                  [
autom4te:                    '/usr/share/autoconf/m4sugar/m4sugar.m4',
autom4te:                    '/usr/share/autoconf/m4sugar/m4sh.m4',
autom4te:                    '/usr/share/autoconf/autoconf/autoconf.m4',
autom4te:                    'aclocal.m4',
autom4te:                    '/dev/null'
autom4te:                  ],
autom4te:                  {
autom4te:                    'AC_CANONICAL_BUILD' => 1,
autom4te:                    'AC_CANONICAL_HOST' => 1,
autom4te:                    'AC_CANONICAL_SYSTEM' => 1,
autom4te:                    'AC_CANONICAL_TARGET' => 1,
autom4te:                    'AC_CONFIG_AUX_DIR' => 1,
autom4te:                    'AC_CONFIG_FILES' => 1,
autom4te:                    'AC_CONFIG_HEADERS' => 1,
autom4te:                    'AC_CONFIG_LIBOBJ_DIR' => 1,
autom4te:                    'AC_CONFIG_LINKS' => 1,
autom4te:                    'AC_CONFIG_MACRO_DIR_TRACE' => 1,
autom4te:                    'AC_CONFIG_SUBDIRS' => 1,
autom4te:                    'AC_DEFINE_TRACE_LITERAL' => 1,
autom4te:                    'AC_FC_FREEFORM' => 1,
autom4te:                    'AC_FC_PP_DEFINE' => 1,
autom4te:                    'AC_FC_PP_SRCEXT' => 1,
autom4te:                    'AC_FC_SRCEXT' => 1,
autom4te:                    'AC_INIT' => 1,
autom4te:                    'AC_LIBSOURCE' => 1,
autom4te:                    'AC_PROG_LIBTOOL' => 1,
autom4te:                    'AC_REQUIRE_AUX_FILE' => 1,
autom4te:                    'AC_SUBST' => 1,
autom4te:                    'AC_SUBST_TRACE' => 1,
autom4te:                    'AH_OUTPUT' => 1,
autom4te:                    'AM_AUTOMAKE_VERSION' => 1,
autom4te:                    'AM_CONDITIONAL' => 1,
autom4te:                    'AM_ENABLE_MULTILIB' => 1,
autom4te:                    'AM_EXTRA_RECURSIVE_TARGETS' => 1,
autom4te:                    'AM_GNU_GETTEXT' => 1,
autom4te:                    'AM_GNU_GETTEXT_INTL_SUBDIR' => 1,
autom4te:                    'AM_INIT_AUTOMAKE' => 1,
autom4te:                    'AM_MAINTAINER_MODE' => 1,
autom4te:                    'AM_MAKEFILE_INCLUDE' => 1,
autom4te:                    'AM_NLS' => 1,
autom4te:                    'AM_PATH_GUILE' => 1,
autom4te:                    'AM_POT_TOOLS' => 1,
autom4te:                    'AM_PROG_AR' => 1,
autom4te:                    'AM_PROG_CC_C_O' => 1,
autom4te:                    'AM_PROG_CXX_C_O' => 1,
autom4te:                    'AM_PROG_F77_C_O' => 1,
autom4te:                    'AM_PROG_FC_C_O' => 1,
autom4te:                    'AM_PROG_LIBTOOL' => 1,
autom4te:                    'AM_PROG_MKDIR_P' => 1,
autom4te:                    'AM_PROG_MOC' => 1,
autom4te:                    'AM_SILENT_RULES' => 1,
autom4te:                    'AM_XGETTEXT_OPTION' => 1,
autom4te:                    'AU_DEFINE' => 1,
autom4te:                    'GTK_DOC_CHECK' => 1,
autom4te:                    'IT_PROG_INTLTOOL' => 1,
autom4te:                    'LT_CONFIG_LTDL_DIR' => 1,
autom4te:                    'LT_INIT' => 1,
autom4te:                    'LT_SUPPORTED_TAG' => 1,
autom4te:                    '_AM_COND_ELSE' => 1,
autom4te:                    '_AM_COND_ENDIF' => 1,
autom4te:                    '_AM_COND_IF' => 1,
autom4te:                    '_AM_MAKEFILE_INCLUDE' => 1,
autom4te:                    '_AM_SUBST_NOTMAKE' => 1,
autom4te:                    '_LT_AC_TAGCONFIG' => 1,
autom4te:                    '_m4_warn' => 1,
autom4te:                    'define' => 1,
autom4te:                    'include' => 1,
autom4te:                    'm4_define' => 1,
autom4te:                    'm4_include' => 1,
autom4te:                    'm4_pattern_allow' => 1,
autom4te:                    'm4_pattern_forbid' => 1,
autom4te:                    'm4_sinclude' => 1,
autom4te:                    'sinclude' => 1
autom4te:                  }
autom4te:                ], 'Autom4te::Request' );
autom4te: running: /tools_x86_64/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf --debug=aflq --fatal-warning --debugfile=autom4te.cache/traces.0t --trace=AC_CANONICAL_BUILD --trace=AC_CANONICAL_HOST --trace=AC_CANONICAL_SYSTEM --trace=AC_CANONICAL_TARGET --trace=AC_CONFIG_AUX_DIR --trace=AC_CONFIG_FILES --trace=AC_CONFIG_HEADERS --trace=AC_CONFIG_LIBOBJ_DIR --trace=AC_CONFIG_LINKS --trace=AC_CONFIG_MACRO_DIR_TRACE --trace=AC_CONFIG_SUBDIRS --trace=AC_DEFINE_TRACE_LITERAL --trace=AC_FC_FREEFORM --trace=AC_FC_PP_DEFINE --trace=AC_FC_PP_SRCEXT --trace=AC_FC_SRCEXT --trace=AC_INIT --trace=AC_LIBSOURCE --trace=AC_PROG_LIBTOOL --trace=AC_REQUIRE_AUX_FILE --trace=AC_SUBST --trace=AC_SUBST_TRACE --trace=AH_OUTPUT --trace=AM_AUTOMAKE_VERSION --trace=AM_CONDITIONAL --trace=AM_ENABLE_MULTILIB --trace=AM_EXTRA_RECURSIVE_TARGETS --trace=AM_GNU_GETTEXT --trace=AM_GNU_GETTEXT_INTL_SUBDIR --trace=AM_INIT_AUTOMAKE --trace=AM_MAINTAINER_MODE --trace=AM_MAKEFILE_INCLUDE --trace=AM_NLS --trace=AM_PATH_GUILE --trace=AM_POT_TOOLS --trace=AM_PROG_AR --trace=AM_PROG_CC_C_O --trace=AM_PROG_CXX_C_O --trace=AM_PROG_F77_C_O --trace=AM_PROG_FC_C_O --trace=AM_PROG_LIBTOOL --trace=AM_PROG_MKDIR_P --trace=AM_PROG_MOC --trace=AM_SILENT_RULES --trace=AM_XGETTEXT_OPTION --trace=AU_DEFINE --trace=GTK_DOC_CHECK --trace=IT_PROG_INTLTOOL --trace=LT_CONFIG_LTDL_DIR --trace=LT_INIT --trace=LT_SUPPORTED_TAG --trace=_AM_COND_ELSE --trace=_AM_COND_ENDIF --trace=_AM_COND_IF --trace=_AM_MAKEFILE_INCLUDE --trace=_AM_SUBST_NOTMAKE --trace=_LT_AC_TAGCONFIG --trace=_m4_warn --trace=define --trace=include --trace=m4_define --trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid --trace=m4_sinclude --trace=sinclude /usr/share/autoconf/m4sugar/m4sugar.m4 /usr/share/autoconf/m4sugar/m4sh.m4 /usr/share/autoconf/autoconf/autoconf.m4 aclocal.m4 /dev/null > autom4te.cache/output.0t
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 to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
autom4te: formatting traces for '/tmp/am4t7DDKJt/warnings': _m4_warn
autom4te: reading /tmp/am4t7DDKJt/warnings
autom4te: formatting traces for '-': AU_DEFINE, define, m4_define
autoupdate: running: /usr/bin/autom4te --language=autoconf --verbose --include=/usr/share/autoconf --trace AU_DEFINE:'_au_defun(@<:@$1@:>@,
autoupdate: @<:@$2@:>@)' --melt /dev/null >/tmp/auCniUF5/au.m4
autom4te: formatting traces for '/tmp/am4tmsyTME/dependencies': include, m4_include
autom4te: up_to_date (autom4te.cache/output.0): up to date
autom4te: the trace request object is:
autom4te: $VAR1 = bless( [
autom4te:                  '0',
autom4te:                  1,
autom4te:                  [
autom4te:                    '/usr/share/autoconf'
autom4te:                  ],
autom4te:                  [
autom4te:                    '/usr/share/autoconf/m4sugar/m4sugar.m4',
autom4te:                    '/usr/share/autoconf/m4sugar/m4sh.m4',
autom4te:                    '/usr/share/autoconf/autoconf/autoconf.m4',
autom4te:                    'aclocal.m4',
autom4te:                    '/dev/null'
autom4te:                  ],
autom4te:                  {
autom4te:                    'AC_CANONICAL_BUILD' => 1,
autom4te:                    'AC_CANONICAL_HOST' => 1,
autom4te:                    'AC_CANONICAL_SYSTEM' => 1,
autom4te:                    'AC_CANONICAL_TARGET' => 1,
autom4te:                    'AC_CONFIG_AUX_DIR' => 1,
autom4te:                    'AC_CONFIG_FILES' => 1,
autom4te:                    'AC_CONFIG_HEADERS' => 1,
autom4te:                    'AC_CONFIG_LIBOBJ_DIR' => 1,
autom4te:                    'AC_CONFIG_LINKS' => 1,
autom4te:                    'AC_CONFIG_MACRO_DIR_TRACE' => 1,
autom4te:                    'AC_CONFIG_SUBDIRS' => 1,
autom4te:                    'AC_DEFINE_TRACE_LITERAL' => 1,
autom4te:                    'AC_FC_FREEFORM' => 1,
autom4te:                    'AC_FC_PP_DEFINE' => 1,
autom4te:                    'AC_FC_PP_SRCEXT' => 1,
autom4te:                    'AC_FC_SRCEXT' => 1,
autom4te:                    'AC_INIT' => 1,
autom4te:                    'AC_LIBSOURCE' => 1,
autom4te:                    'AC_PROG_LIBTOOL' => 1,
autom4te:                    'AC_REQUIRE_AUX_FILE' => 1,
autom4te:                    'AC_SUBST' => 1,
autom4te:                    'AC_SUBST_TRACE' => 1,
autom4te:                    'AH_OUTPUT' => 1,
autom4te:                    'AM_AUTOMAKE_VERSION' => 1,
autom4te:                    'AM_CONDITIONAL' => 1,
autom4te:                    'AM_ENABLE_MULTILIB' => 1,
autom4te:                    'AM_EXTRA_RECURSIVE_TARGETS' => 1,
autom4te:                    'AM_GNU_GETTEXT' => 1,
autom4te:                    'AM_GNU_GETTEXT_INTL_SUBDIR' => 1,
autom4te:                    'AM_INIT_AUTOMAKE' => 1,
autom4te:                    'AM_MAINTAINER_MODE' => 1,
autom4te:                    'AM_MAKEFILE_INCLUDE' => 1,
autom4te:                    'AM_NLS' => 1,
autom4te:                    'AM_PATH_GUILE' => 1,
autom4te:                    'AM_POT_TOOLS' => 1,
autom4te:                    'AM_PROG_AR' => 1,
autom4te:                    'AM_PROG_CC_C_O' => 1,
autom4te:                    'AM_PROG_CXX_C_O' => 1,
autom4te:                    'AM_PROG_F77_C_O' => 1,
autom4te:                    'AM_PROG_FC_C_O' => 1,
autom4te:                    'AM_PROG_LIBTOOL' => 1,
autom4te:                    'AM_PROG_MKDIR_P' => 1,
autom4te:                    'AM_PROG_MOC' => 1,
autom4te:                    'AM_SILENT_RULES' => 1,
autom4te:                    'AM_XGETTEXT_OPTION' => 1,
autom4te:                    'AU_DEFINE' => 1,
autom4te:                    'GTK_DOC_CHECK' => 1,
autom4te:                    'IT_PROG_INTLTOOL' => 1,
autom4te:                    'LT_CONFIG_LTDL_DIR' => 1,
autom4te:                    'LT_INIT' => 1,
autom4te:                    'LT_SUPPORTED_TAG' => 1,
autom4te:                    '_AM_COND_ELSE' => 1,
autom4te:                    '_AM_COND_ENDIF' => 1,
autom4te:                    '_AM_COND_IF' => 1,
autom4te:                    '_AM_MAKEFILE_INCLUDE' => 1,
autom4te:                    '_AM_SUBST_NOTMAKE' => 1,
autom4te:                    '_LT_AC_TAGCONFIG' => 1,
autom4te:                    '_m4_warn' => 1,
autom4te:                    'define' => 1,
autom4te:                    'include' => 1,
autom4te:                    'm4_define' => 1,
autom4te:                    'm4_include' => 1,
autom4te:                    'm4_pattern_allow' => 1,
autom4te:                    'm4_pattern_forbid' => 1,
autom4te:                    'm4_sinclude' => 1,
autom4te:                    'sinclude' => 1
autom4te:                  }
autom4te:                ], 'Autom4te::Request' );
autom4te: formatting traces for '/tmp/am4tmsyTME/warnings': _m4_warn
autom4te: reading /tmp/am4tmsyTME/warnings
autom4te: formatting traces for '-': AU_DEFINE
autoupdate: running: /tools_x86_64/bin/m4 --include=/tmp/auCniUF5 --include=/usr/share/autoconf /tmp/auCniUF5/input.m4 > /tmp/auCniUF5/updated
configure.in:121: warning: The preprocessor macro 'STDC_HEADERS' is obsolete.
   Except in unusual embedded environments, you can safely include all
   C89 headers unconditionally.
configure.in:500: warning: Update your code to rely only on HAVE_SYS_TIME_H,
then remove this warning and the obsolete code below it.
All current systems provide time.h; it need not be checked for.
Not all systems provide sys/time.h, but those that do, all allow
you to include it and time.h simultaneously.
configure.in:505: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use AC_PROG_CC

autoupdate: 'configure.in' is updated
cd /usr/src/collectd-4.10.9 && autoreconf -vfi
autoreconf: export WARNINGS=
autoreconf: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: Entering directory '.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force -I libltdl/m4
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: configure.in: tracing
autoreconf: configure.in: adding subdirectory libltdl to autoreconf
autoreconf: Entering directory 'libltdl'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force --ltdl
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/compile'
libtoolize: copying file 'config/config.guess'
libtoolize: copying file 'config/config.sub'
libtoolize: copying file 'config/depcomp'
libtoolize: copying file 'config/install-sh'
libtoolize: copying file 'config/missing'
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltargz.m4'
libtoolize: You should add the contents of 'm4/ltargz.m4' to 'aclocal.m4'.
libtoolize: copying file 'm4/ltdl.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: putting libltdl files in LT_CONFIG_LTDL_DIR, '.'.
libtoolize: copying file './COPYING.LIB'
libtoolize: creating file './Makefile.am'
libtoolize: copying file './README'
libtoolize: creating file './configure.ac'
libtoolize: creating file './aclocal.m4'
libtoolize: creating file './Makefile.in'
libtoolize: copying file './config-h.in'
libtoolize: creating file './configure'
libtoolize: copying file './libltdl/lt__alloc.h'
libtoolize: copying file './libltdl/lt__argz_.h'
libtoolize: copying file './libltdl/lt__dirent.h'
libtoolize: copying file './libltdl/lt__glibc.h'
libtoolize: copying file './libltdl/lt__private.h'
libtoolize: copying file './libltdl/lt__strl.h'
libtoolize: copying file './libltdl/lt_dlloader.h'
libtoolize: copying file './libltdl/lt_error.h'
libtoolize: copying file './libltdl/lt_system.h'
libtoolize: copying file './libltdl/slist.h'
libtoolize: copying file './loaders/dld_link.c'
libtoolize: copying file './loaders/dlopen.c'
libtoolize: copying file './loaders/dyld.c'
libtoolize: copying file './loaders/load_add_on.c'
libtoolize: copying file './loaders/loadlibrary.c'
libtoolize: copying file './loaders/preopen.c'
libtoolize: copying file './loaders/shl_load.c'
libtoolize: copying file './lt__alloc.c'
libtoolize: copying file './lt__argz.c'
libtoolize: copying file './lt__dirent.c'
libtoolize: copying file './lt__strl.c'
libtoolize: copying file './lt_dlloader.c'
libtoolize: copying file './lt_error.c'
libtoolize: copying file './ltdl.c'
libtoolize: copying file './ltdl.h'
libtoolize: copying file './slist.c'
libtoolize: Remember to add 'LTDL_INIT' to configure.ac.
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I m4
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory 'libltdl'
autoreconf: running: libtoolize --copy --force --ltdl --ltdl
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'libltdl/config'.
libtoolize: copying file 'libltdl/config/compile'
libtoolize: copying file 'libltdl/config/config.guess'
libtoolize: copying file 'libltdl/config/config.sub'
libtoolize: copying file 'libltdl/config/depcomp'
libtoolize: copying file 'libltdl/config/install-sh'
libtoolize: copying file 'libltdl/config/missing'
libtoolize: copying file 'libltdl/config/ltmain.sh'
libtoolize: putting macros in 'libltdl/m4'.
libtoolize: copying file 'libltdl/m4/libtool.m4'
libtoolize: copying file 'libltdl/m4/ltargz.m4'
libtoolize: You should add the contents of 'libltdl/m4/ltargz.m4' to 'aclocal.m4'.
libtoolize: copying file 'libltdl/m4/ltdl.m4'
libtoolize: copying file 'libltdl/m4/ltoptions.m4'
libtoolize: copying file 'libltdl/m4/ltsugar.m4'
libtoolize: copying file 'libltdl/m4/ltversion.m4'
libtoolize: copying file 'libltdl/m4/lt~obsolete.m4'
libtoolize: putting libltdl files in 'libltdl'.
libtoolize: copying file 'libltdl/COPYING.LIB'
libtoolize: creating file 'libltdl/Makefile.am'
libtoolize: copying file 'libltdl/README'
libtoolize: creating file 'libltdl/configure.ac'
libtoolize: creating file 'libltdl/aclocal.m4'
libtoolize: creating file 'libltdl/Makefile.in'
libtoolize: copying file 'libltdl/config-h.in'
libtoolize: creating file 'libltdl/configure'
libtoolize: copying file 'libltdl/libltdl/lt__alloc.h'
libtoolize: copying file 'libltdl/libltdl/lt__argz_.h'
libtoolize: copying file 'libltdl/libltdl/lt__dirent.h'
libtoolize: copying file 'libltdl/libltdl/lt__glibc.h'
libtoolize: copying file 'libltdl/libltdl/lt__private.h'
libtoolize: copying file 'libltdl/libltdl/lt__strl.h'
libtoolize: copying file 'libltdl/libltdl/lt_dlloader.h'
libtoolize: copying file 'libltdl/libltdl/lt_error.h'
libtoolize: copying file 'libltdl/libltdl/lt_system.h'
libtoolize: copying file 'libltdl/libltdl/slist.h'
libtoolize: copying file 'libltdl/loaders/dld_link.c'
libtoolize: copying file 'libltdl/loaders/dlopen.c'
libtoolize: copying file 'libltdl/loaders/dyld.c'
libtoolize: copying file 'libltdl/loaders/load_add_on.c'
libtoolize: copying file 'libltdl/loaders/loadlibrary.c'
libtoolize: copying file 'libltdl/loaders/preopen.c'
libtoolize: copying file 'libltdl/loaders/shl_load.c'
libtoolize: copying file 'libltdl/lt__alloc.c'
libtoolize: copying file 'libltdl/lt__argz.c'
libtoolize: copying file 'libltdl/lt__dirent.c'
libtoolize: copying file 'libltdl/lt__strl.c'
libtoolize: copying file 'libltdl/lt_dlloader.c'
libtoolize: copying file 'libltdl/lt_error.c'
libtoolize: copying file 'libltdl/ltdl.c'
libtoolize: copying file 'libltdl/ltdl.h'
libtoolize: copying file 'libltdl/slist.c'
libtoolize: Remember to add 'LTDL_INIT' to configure.in.
libtoolize: Remember to add 'LT_CONFIG_LTDL_DIR([libltdl])' to 'configure.in'.
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([libltdl/m4])' to configure.in,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: configure.in: not using Intltool
autoreconf: configure.in: not using Gtkdoc
autoreconf: running: aclocal --force -I libltdl/m4
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: running: /usr/bin/autoconf --force
configure.in:51: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:743: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:736: AC_PROG_LEX is expanded from...
configure.in:51: the top level
configure.in:125: warning: The preprocessor macro 'STDC_HEADERS' is obsolete.
configure.in:125:   Except in unusual embedded environments, you can safely include all
configure.in:125:   C89 headers unconditionally.
configure.in:512: warning: Update your code to rely only on HAVE_SYS_TIME_H,
configure.in:512: then remove this warning and the obsolete code below it.
configure.in:512: All current systems provide time.h; it need not be checked for.
configure.in:512: Not all systems provide sys/time.h, but those that do, all allow
configure.in:512: you to include it and time.h simultaneously.
configure.in:530: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use AC_PROG_CC
configure.in:533: warning: ac_ext=c
configure.in:533: ac_cpp='$CPP $CPPFLAGS'
configure.in:533: ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
configure.in:533: ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
configure.in:533: ac_compiler_gnu=$ac_cv_c_compiler_gnu
configure.in:533: if test -n "$ac_tool_prefix"; then
configure.in:533:   # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args.
configure.in:533: set dummy ${ac_tool_prefix}gcc; ac_word=$2
configure.in:533: { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
configure.in:533: printf %s "checking for $ac_word... " >&6; }
configure.in:533: if test ${ac_cv_prog_CC+y}
configure.in:533: then :
configure.in:533:   printf %s "(cached) " >&6
configure.in:533: else case e in #(
configure.in:533:   e) if test -n "$CC"; then
configure.in:533:   ac_cv_prog_CC="$CC" # Let the user override the test.
configure.in:533: else
configure.in:533: as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
configure.in:533: for as_dir in $PATH
configure.in:533: do
configure.in:533:   IFS=$as_save_IFS
configure.in:533:   case $as_dir in #(((
configure.in:533:     '') as_dir=./ ;;
configure.in:533:     */) ;;
configure.in:533:     *) as_dir=$as_dir/ ;;
configure.in:533:   esac
configure.in:533:     for ac_exec_ext in '' $ac_executable_extensions; do
configure.in:533:   if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
configure.in:533:     ac_cv_prog_CC="${ac_tool_prefix}gcc"
configure.in:533:     printf "%s\n" "$as_me:${as_lineno-$LINENO}: found $as_dir$ac_word$ac_exec_ext" >&5
configure.in:533:     break 2
configure.in:533:   fi
configure.in:533: done
configure.in:533:   done
configure.in:533: IFS=$as_save_IFS
configure.in:533:
configure.in:533: fi ;;
configure.in:533: esac
configure.in:533: fi
configure.in:533: CC=$ac_cv_prog_CC
configure.in:533: if test -n "$CC"; then
configure.in:533:   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $CC" >&5
configure.in:533: printf "%s\n" "$CC" >&6; }
configure.in:533: else
configure.in:533:   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
configure.in:533: printf "%s\n" "no" >&6; }
configure.in:533: fi
configure.in:533:
configure.in:533:
configure.in:533: fi
configure.in:533: if test -z "$ac_cv_prog_CC"; then
configure.in:533:   ac_ct_CC=$CC
configure.in:533:   # Extract the first word of "gcc", so it can be a program name with args.
configure.in:533: set dummy gcc; ac_word=$2
configure.in:533: { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
configure.in:533: printf %s "checking for $ac_word... " >&6; }
configure.in:533: if test ${ac_cv_prog_ac_ct_CC+y}
configure.in:533: then :
configure.in:533:   printf %s "(cached) " >&6
configure.in:533: else case e in #(
configure.in:533:   e) if test -n "$ac_ct_CC"; then
configure.in:533:   ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
configure.in:533: else
configure.in:533: as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
configure.in:533: for as_dir in $PATH
configure.in:533: do
configure.in:533:   IFS=$as_save_IFS
configure.in:533:   case $as_dir in #(((
configure.in:533:     '') as_dir=./ ;;
configure.in:533:     */) ;;
configure.in:533:     *) as_dir=$as_dir/ ;;
configure.in:533:   esac
configure.in:533:     for ac_exec_ext in '' $ac_executable_extensions; do
configure.in:533:   if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
configure.in:533:     ac_cv_prog_ac_ct_CC="gcc"
configure.in:533:     printf "%s\n" "$as_me:${as_lineno-$LINENO}: found $as_dir$ac_word$ac_exec_ext" >&5
configure.in:533:     break 2
configure.in:533:   fi
configure.in:533: done
configure.in:533:   done
configure.in:533: IFS=$as_save_IFS
configure.in:533:
configure.in:533: fi ;;
configure.in:533: esac
configure.in:533: fi
configure.in:533: ac_ct_CC=$ac_cv_prog_ac_ct_CC
configure.in:533: if test -n "$ac_ct_CC"; then
configure.in:533:   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CC" >&5
configure.in:533: printf "%s\n" "$ac_ct_CC" >&6; }
configure.in:533: else
configure.in:533:   { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: no" >&5
configure.in:533: printf "%s\n" "no" >&6; }
configure.in:533: fi
configure.in:533:
configure.in:533:   if test "x$ac_ct_CC" = x; then
configure.in:533:     CC=""
configure.in:533:   else
configure.in:533:     case $cross_compiling:$ac_tool_warned in
configure.in:533: yes: is m4_require'd but not m4_defun'd
./lib/autoconf/programs.m4:189: _AC_TOOL_WARN is expanded from...
./lib/autoconf/programs.m4:221: AC_CHECK_TOOL is expanded from...
./lib/autoconf/c.m4:460: AC_PROG_CC is expanded from...
configure.in:533: the top level
autoreconf: running: /usr/bin/autoheader --force
autoheader: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: running: automake --add-missing --copy --force-missing
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
Makefile.am:5: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: Leaving directory '.'
cd /usr/src/collectd-4.10.9/libltdl && autoreconf -vfi
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force --ltdl
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/compile'
libtoolize: copying file 'config/config.guess'
libtoolize: copying file 'config/config.sub'
libtoolize: copying file 'config/depcomp'
libtoolize: copying file 'config/install-sh'
libtoolize: copying file 'config/missing'
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltargz.m4'
libtoolize: copying file 'm4/ltdl.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: putting libltdl files in LT_CONFIG_LTDL_DIR, '.'.
libtoolize: copying file './COPYING.LIB'
libtoolize: creating file './Makefile.am'
libtoolize: copying file './README'
libtoolize: creating file './configure.ac'
libtoolize: creating file './aclocal.m4'
libtoolize: creating file './Makefile.in'
libtoolize: copying file './config-h.in'
libtoolize: creating file './configure'
libtoolize: copying file './libltdl/lt__alloc.h'
libtoolize: copying file './libltdl/lt__argz_.h'
libtoolize: copying file './libltdl/lt__dirent.h'
libtoolize: copying file './libltdl/lt__glibc.h'
libtoolize: copying file './libltdl/lt__private.h'
libtoolize: copying file './libltdl/lt__strl.h'
libtoolize: copying file './libltdl/lt_dlloader.h'
libtoolize: copying file './libltdl/lt_error.h'
libtoolize: copying file './libltdl/lt_system.h'
libtoolize: copying file './libltdl/slist.h'
libtoolize: copying file './loaders/dld_link.c'
libtoolize: copying file './loaders/dlopen.c'
libtoolize: copying file './loaders/dyld.c'
libtoolize: copying file './loaders/load_add_on.c'
libtoolize: copying file './loaders/loadlibrary.c'
libtoolize: copying file './loaders/preopen.c'
libtoolize: copying file './loaders/shl_load.c'
libtoolize: copying file './lt__alloc.c'
libtoolize: copying file './lt__argz.c'
libtoolize: copying file './lt__dirent.c'
libtoolize: copying file './lt__strl.c'
libtoolize: copying file './lt_dlloader.c'
libtoolize: copying file './lt_error.c'
libtoolize: copying file './ltdl.c'
libtoolize: copying file './ltdl.h'
libtoolize: copying file './slist.c'
libtoolize: Remember to add 'LTDL_INIT' to configure.ac.
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I m4
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory '.'

Regards,
Adolf.

> 
>> On 13 Nov 2024, at 10:30, Adolf Belka <adolf.belka(a)ipfire.org> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>
>>    Configure scripts no longer support pre-1989 C compilers.
>>    Specifically, compilers that *only* implement the original “K&R”
>>    function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>    C 1989.
>>
>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>
> 

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

Hi Michael,

I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710


18706   if test "x$ac_ct_CC" = x; then
18707     CC=""
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 with host triplet" >&2;}
18714 ac_tool_warned=yes ;;
18715 esac
18716     CC=$ac_ct_CC
18717   fi
18718 else
18719   CC="$ac_cv_prog_CC"
18720 fi

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 command

Regards,
Adolf.


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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
> 
> Is there any output of that command? There should be some warnings which might 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:
>>
>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>
>>    Configure scripts no longer support pre-1989 C compilers.
>>    Specifically, compilers that *only* implement the original “K&R”
>>    function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>    C 1989.
>>
>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>
> 

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 5550 bytes --]

Hi Michael,

Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.

Regards,

Adolf.

On 19/11/2024 14:43, Adolf Belka wrote:
> Hi Michael,
>
> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>
>
> 18706   if test "x$ac_ct_CC" = x; then
> 18707     CC=""
> 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 with host triplet" >&2;}
> 18714 ac_tool_warned=yes ;;
> 18715 esac
> 18716     CC=$ac_ct_CC
> 18717   fi
> 18718 else
> 18719   CC="$ac_cv_prog_CC"
> 18720 fi
>
> 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 command
>
> Regards,
> Adolf.
>
>
> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>
>> Is there any output of that command? There should be some warnings which might 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:
>>>
>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>
>>>    Configure scripts no longer support pre-1989 C compilers.
>>>    Specifically, compilers that *only* implement the original “K&R”
>>>    function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>    C 1989.
>>>
>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>>
>>
>

Re: Failure building collectd when autoconf has been updated to 2.72

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6281 bytes --]

Let’s 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. Let’s see…

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.

I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.

Best,
-Michael

> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> Hi Michael,
> 
> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
> 
> Regards,
> 
> Adolf.
> 
>> On 19/11/2024 14:43, Adolf Belka wrote:
>> Hi Michael,
>> 
>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>> 
>> 
>> 18706   if test "x$ac_ct_CC" = x; then
>> 18707     CC=""
>> 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 with host triplet" >&2;}
>> 18714 ac_tool_warned=yes ;;
>> 18715 esac
>> 18716     CC=$ac_ct_CC
>> 18717   fi
>> 18718 else
>> 18719   CC="$ac_cv_prog_CC"
>> 18720 fi
>> 
>> 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 command
>> 
>> Regards,
>> Adolf.
>> 
>> 
>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>> Is there any output of that command? There should be some warnings which might 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:
>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>    Configure scripts no longer support pre-1989 C compilers.
>>>>    Specifically, compilers that *only* implement the original “K&R”
>>>>    function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>    C 1989.
>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 7506 bytes --]

Hi Michael,

On 20/11/2024 19:25, Michael Tremer wrote:
> Let’s 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. Let’s see…
> 
> 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.

I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.

Unfortunately it failed to build and had the following error message

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 to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
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

> 
> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.

As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x

Regards,

Adolf.

> 
> Best,
> -Michael
> 
>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>> Hi Michael,
>>
>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>
>> Regards,
>>
>> Adolf.
>>
>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>> Hi Michael,
>>>
>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>
>>>
>>> 18706   if test "x$ac_ct_CC" = x; then
>>> 18707     CC=""
>>> 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 with host triplet" >&2;}
>>> 18714 ac_tool_warned=yes ;;
>>> 18715 esac
>>> 18716     CC=$ac_ct_CC
>>> 18717   fi
>>> 18718 else
>>> 18719   CC="$ac_cv_prog_CC"
>>> 18720 fi
>>>
>>> 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 command
>>>
>>> Regards,
>>> Adolf.
>>>
>>>
>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>     Specifically, compilers that *only* implement the original “K&R”
>>>>>     function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>     C 1989.
>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.

Re: Failure building collectd when autoconf has been updated to 2.72

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8380 bytes --]

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’t be much easier.

There is a migration script here:

  https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108

Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?

If we can then run the migration script on existing systems we might almost be there…

-Michael

> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 20/11/2024 19:25, Michael Tremer wrote:
>> Let’s 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. Let’s see…
>> 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.
> 
> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
> 
> Unfortunately it failed to build and had the following error message
> 
> 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 to.
> If you have problems, you may need to regenerate the build system entirely.
> To do so, use the procedure documented by the package, typically `autoreconf'.
> 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
> 
>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
> 
> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
> 
> Regards,
> 
> Adolf.
> 
>> Best,
>> -Michael
>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> Hi Michael,
>>> 
>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>> Hi Michael,
>>>> 
>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>> 
>>>> 
>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>> 18707     CC=""
>>>> 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 with host triplet" >&2;}
>>>> 18714 ac_tool_warned=yes ;;
>>>> 18715 esac
>>>> 18716     CC=$ac_ct_CC
>>>> 18717   fi
>>>> 18718 else
>>>> 18719   CC="$ac_cv_prog_CC"
>>>> 18720 fi
>>>> 
>>>> 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 command
>>>> 
>>>> Regards,
>>>> Adolf.
>>>> 
>>>> 
>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>    Configure scripts no longer support pre-1989 C compilers.
>>>>>>    Specifically, compilers that *only* implement the original “K&R”
>>>>>>    function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>    C 1989.
>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
> 

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 8685 bytes --]

Hi Michael,

On 23/11/2024 10:12, Michael Tremer wrote:
> 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’t be much easier.
> 
> There is a migration script here:
> 
>    https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108
> 
> Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?

I will give that a go and see what happens and we can work from there.

Regards,

Adolf

> 
> If we can then run the migration script on existing systems we might almost be there…
> 
> -Michael
> 
>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 20/11/2024 19:25, Michael Tremer wrote:
>>> Let’s 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. Let’s see…
>>> 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.
>>
>> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
>>
>> Unfortunately it failed to build and had the following error message
>>
>> 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 to.
>> If you have problems, you may need to regenerate the build system entirely.
>> To do so, use the procedure documented by the package, typically `autoreconf'.
>> 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
>>
>>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
>>
>> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
>>
>> Regards,
>>
>> Adolf.
>>
>>> Best,
>>> -Michael
>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>> Hi Michael,
>>>>
>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>> Hi Michael,
>>>>>
>>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>>>
>>>>>
>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>> 18707     CC=""
>>>>> 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 with host triplet" >&2;}
>>>>> 18714 ac_tool_warned=yes ;;
>>>>> 18715 esac
>>>>> 18716     CC=$ac_ct_CC
>>>>> 18717   fi
>>>>> 18718 else
>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>> 18720 fi
>>>>>
>>>>> 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 command
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>
>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>>>     Specifically, compilers that *only* implement the original “K&R”
>>>>>>>     function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>>     C 1989.
>>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>
> 

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 11365 bytes --]

Hi Michael,

On 23/11/2024 13:09, Adolf Belka wrote:
> Hi Michael,
>
> On 23/11/2024 10:12, Michael Tremer wrote:
>> 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’t be much easier.
>>
>> There is a migration script here:
>>
>> https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108
>>
>> Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?
>
> I will give that a go and see what happens and we can work from there.
>
I gave it a go and have been very successful.

Building the collectd-5.12.0 did result in various build failures. I think I had to do around 7 build attempts but I progressively moved forward and eventually succeeded in a successful build of the new collectd and then the rest of the IPFire build.

I then installed the CU190 iso with collectd-5.12.0 into a vm system. The fresh install already updates all the rrd files with the updated changes from 4.x to 5.x

There were a range of graphs that failed due to, for example, a DS named ping not being found in the ping rrd file.

Checking the ping rrd file with rrdtool info I found that in 5.x the ping rrd file DS is now "value" in place of "ping".

I then found the DEF statement in graphs.pl for the ping graph and changed the rrd:ping section to rrd:value and the graph started operating and collecting data. I also did it with the conntrack entry which changed from "entropy" to "value" and again the graph started working.

So I know now what I need to do - find all the places where the DS has changed in an rrd file and correct those in the IPFire code.

I tested out the migrate-4-5.px file and in its first phase it creates a script which will update the DS values to their new versions. I can use the output of that script to identify which files have got a change in them, find where in the code that file is accessed and modify it.

We will also need to use the migrate script in the restore portion of the backup process as the rrd files are in the backup and restoring them will give files with a DS of "ping" for the ping rrd one, which will not be recognised with the modified DS values in graphs.pl etc.

Running the migrate script after doing a restore will convert all the DS values to their 5.x values. If the entries in the backup are already updated then the rrdtool tune command run by the migrate script will give the error message

ERROR: unknown data source name 'ping'

in the example of the ping rrd file but in that case the entry is left as it is so the migrate script should be able to work on restores with the 4.x and 5.x rrd values.

It looks like both DS names and DS types have been changed for some of the plugins.


Anyway, things are looking very promising. Should be able to look at testing this out in unstable early in the new year.


Regards,

Adolf.

> Regards,
>
> Adolf
>
>>
>> If we can then run the migration script on existing systems we might almost be there…
>>
>> -Michael
>>
>>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> On 20/11/2024 19:25, Michael Tremer wrote:
>>>> Let’s 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. Let’s see…
>>>> 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.
>>>
>>> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
>>>
>>> Unfortunately it failed to build and had the following error message
>>>
>>> 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 to.
>>> If you have problems, you may need to regenerate the build system entirely.
>>> To do so, use the procedure documented by the package, typically `autoreconf'.
>>> 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
>>>
>>>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
>>>
>>> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>>> Best,
>>>> -Michael
>>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>>>
>>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>>>>
>>>>>>
>>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>>> 18707     CC=""
>>>>>> 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 with host triplet" >&2;}
>>>>>> 18714 ac_tool_warned=yes ;;
>>>>>> 18715 esac
>>>>>> 18716     CC=$ac_ct_CC
>>>>>> 18717   fi
>>>>>> 18718 else
>>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>>> 18720 fi
>>>>>>
>>>>>> 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 command
>>>>>>
>>>>>> Regards,
>>>>>> Adolf.
>>>>>>
>>>>>>
>>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>>>>     Specifically, compilers that *only* implement the original “K&R”
>>>>>>>>     function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>>>     C 1989.
>>>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>>
>>
>

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 13602 bytes --]

Hi Michael,


On 25/11/2024 19:25, Adolf Belka wrote:
> Hi Michael,
>
> On 23/11/2024 13:09, Adolf Belka wrote:
>> Hi Michael,
>>
>> On 23/11/2024 10:12, Michael Tremer wrote:
>>> 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’t be much 
>>> easier.
>>>
>>> There is a migration script here:
>>>
>>> https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108 
>>>
>>>
>>> Should we maybe start with building a new branch with the latest 
>>> version of collectd 5 and simply check if a newly installed system 
>>> is still working? I don’t think there will be that many changes 
>>> required. Would you be up for giving that a go?
>>
>> I will give that a go and see what happens and we can work from there.
>>
> I gave it a go and have been very successful.
>
> Building the collectd-5.12.0 did result in various build failures. I 
> think I had to do around 7 build attempts but I progressively moved 
> forward and eventually succeeded in a successful build of the new 
> collectd and then the rest of the IPFire build.
>
> I then installed the CU190 iso with collectd-5.12.0 into a vm system. 
> The fresh install already updates all the rrd files with the updated 
> changes from 4.x to 5.x
>
> There were a range of graphs that failed due to, for example, a DS 
> named ping not being found in the ping rrd file.
>
> Checking the ping rrd file with rrdtool info I found that in 5.x the 
> ping rrd file DS is now "value" in place of "ping".
>
> I then found the DEF statement in graphs.pl for the ping graph and 
> changed the rrd:ping section to rrd:value and the graph started 
> operating and collecting data. I also did it with the conntrack entry 
> which changed from "entropy" to "value" and again the graph started 
> working.
>
> So I know now what I need to do - find all the places where the DS has 
> changed in an rrd file and correct those in the IPFire code.
>
> I tested out the migrate-4-5.px file and in its first phase it creates 
> a script which will update the DS values to their new versions. I can 
> use the output of that script to identify which files have got a 
> change in them, find where in the code that file is accessed and 
> modify it.
>
> We will also need to use the migrate script in the restore portion of 
> the backup process as the rrd files are in the backup and restoring 
> them will give files with a DS of "ping" for the ping rrd one, which 
> will not be recognised with the modified DS values in graphs.pl etc.
>
> Running the migrate script after doing a restore will convert all the 
> DS values to their 5.x values. If the entries in the backup are 
> already updated then the rrdtool tune command run by the migrate 
> script will give the error message
>
> ERROR: unknown data source name 'ping'
>
> in the example of the ping rrd file but in that case the entry is left 
> as it is so the migrate script should be able to work on restores with 
> the 4.x and 5.x rrd values.
>
> It looks like both DS names and DS types have been changed for some of 
> the plugins.
>
>
> Anyway, things are looking very promising. Should be able to look at 
> testing this out in unstable early in the new year.
>
So it turned out to be much easier than any of us thought. The changes 
needed in graphs.pl are only 4 lines to be changed.
The interface directory becomes the interface-$interface directory and 
there are two lines for that and then the rrd:ping (gateway graph) and 
rrd:entropy (conntrack graph) entries need to both be changed to rrd:value.

I also added the migrate-4-5 script into backup.pl

Tested all above out on my vm testbed. Fresh install of IPFire gave the 
new names and directories as required and everything worked. I also then 
restored an older backup that had the old names etc and the code in 
backup.pl also worked without any hitch. The graphs all worked.

The only thing I haven't done yet is adding the migrate code I put into 
backup.pl into the update.sh script. I will do that when next is updated 
to become CU191.

I will also just confirm that with the new collectd is happy to build 
with autoconf-2.72. Everything I have done so far is with the existing 
autoconf-2.71.

I think that the collectd update should be good to go into Core Update 
192 early in the new year.

Regards,

Adolf.

>
> Regards,
>
> Adolf.
>
>> Regards,
>>
>> Adolf
>>
>>>
>>> If we can then run the migration script on existing systems we might 
>>> almost be there…
>>>
>>> -Michael
>>>
>>>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> On 20/11/2024 19:25, Michael Tremer wrote:
>>>>> Let’s 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. Let’s see…
>>>>> 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.
>>>>
>>>> I removed the two patches and also removed the two autoreconf 
>>>> commands, leaving the autoupdate command in place.
>>>>
>>>> Unfortunately it failed to build and had the following error message
>>>>
>>>> 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 to.
>>>> If you have problems, you may need to regenerate the build system 
>>>> entirely.
>>>> To do so, use the procedure documented by the package, typically 
>>>> `autoreconf'.
>>>> 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
>>>>
>>>>> I can’t remember what has stopped us from moving with upstream 
>>>>> apart from the RRD file format. If this all doesn’t work, maybe we 
>>>>> should look at this all again and see if we can’t migrate to the 
>>>>> latest upstream version again.
>>>>
>>>> As far as I can remember it was mentioned that the issue was the 
>>>> changed format and RRD being used in so many places making the 
>>>> update require changes in so many places in IPFire-2.x
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>>> Best,
>>>>> -Michael
>>>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> 
>>>>>> wrote:
>>>>>> Hi Michael,
>>>>>>
>>>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in 
>>>>>> that case 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 is the one with a 
>>>>>> missing ), all the rest have a yes:) entry.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adolf.
>>>>>>
>>>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> I obtained the configure created by the autoreconf etc and I 
>>>>>>> have found the error. Here is the affected line 18710
>>>>>>>
>>>>>>>
>>>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>>>> 18707     CC=""
>>>>>>> 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 with host triplet" >&2;}
>>>>>>> 18714 ac_tool_warned=yes ;;
>>>>>>> 18715 esac
>>>>>>> 18716     CC=$ac_ct_CC
>>>>>>> 18717   fi
>>>>>>> 18718 else
>>>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>>>> 18720 fi
>>>>>>>
>>>>>>> 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 command
>>>>>>>
>>>>>>> Regards,
>>>>>>> Adolf.
>>>>>>>
>>>>>>>
>>>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119 
>>>>>>>>
>>>>>>>> Is there any output of that command? There should be some 
>>>>>>>> warnings which might 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:
>>>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The 
>>>>>>>>> one that doesn't mention that is the following change:-
>>>>>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>>>>>     Specifically, compilers that *only* implement the original 
>>>>>>>>> “K&R”
>>>>>>>>>     function definition syntax, and not the newer “prototyped” 
>>>>>>>>> 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 “C23”), 
>>>>>>>>> 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’t implement a core 
>>>>>>>>> feature of
>>>>>>>>>     C 1989.
>>>>>>>>> However I am unable to figure out from this if the problem I 
>>>>>>>>> am experiencing is related to this or not. I would not have 
>>>>>>>>> thought so as I don't believe 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 aspect 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.
>>>>
>>>
>>

-- 
Sent from my laptop

Re: Failure building collectd when autoconf has been updated to 2.72

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 13241 bytes --]

Okay, this sounds really good then and seems to be a lot easier than expected.

Are there any changes we would like to make to the graphs in this step? Remove? Add new things?

> On 29 Nov 2024, at 19:24, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> 
> On 25/11/2024 19:25, Adolf Belka wrote:
>> Hi Michael,
>> 
>> On 23/11/2024 13:09, Adolf Belka wrote:
>>> Hi Michael,
>>> 
>>> On 23/11/2024 10:12, Michael Tremer wrote:
>>>> 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’t be much easier.
>>>> 
>>>> There is a migration script here:
>>>> 
>>>> https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108 
>>>> 
>>>> Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?
>>> 
>>> I will give that a go and see what happens and we can work from there.
>>> 
>> I gave it a go and have been very successful.
>> 
>> Building the collectd-5.12.0 did result in various build failures. I think I had to do around 7 build attempts but I progressively moved forward and eventually succeeded in a successful build of the new collectd and then the rest of the IPFire build.
>> 
>> I then installed the CU190 iso with collectd-5.12.0 into a vm system. The fresh install already updates all the rrd files with the updated changes from 4.x to 5.x
>> 
>> There were a range of graphs that failed due to, for example, a DS named ping not being found in the ping rrd file.
>> 
>> Checking the ping rrd file with rrdtool info I found that in 5.x the ping rrd file DS is now "value" in place of "ping".
>> 
>> I then found the DEF statement in graphs.pl for the ping graph and changed the rrd:ping section to rrd:value and the graph started operating and collecting data. I also did it with the conntrack entry which changed from "entropy" to "value" and again the graph started working.
>> 
>> So I know now what I need to do - find all the places where the DS has changed in an rrd file and correct those in the IPFire code.
>> 
>> I tested out the migrate-4-5.px file and in its first phase it creates a script which will update the DS values to their new versions. I can use the output of that script to identify which files have got a change in them, find where in the code that file is accessed and modify it.
>> 
>> We will also need to use the migrate script in the restore portion of the backup process as the rrd files are in the backup and restoring them will give files with a DS of "ping" for the ping rrd one, which will not be recognised with the modified DS values in graphs.pl etc.
>> 
>> Running the migrate script after doing a restore will convert all the DS values to their 5.x values. If the entries in the backup are already updated then the rrdtool tune command run by the migrate script will give the error message
>> 
>> ERROR: unknown data source name 'ping'
>> 
>> in the example of the ping rrd file but in that case the entry is left as it is so the migrate script should be able to work on restores with the 4.x and 5.x rrd values.
>> 
>> It looks like both DS names and DS types have been changed for some of the plugins.
>> 
>> 
>> Anyway, things are looking very promising. Should be able to look at testing this out in unstable early in the new year.
>> 
> So it turned out to be much easier than any of us thought. The changes needed in graphs.pl are only 4 lines to be changed.
> The interface directory becomes the interface-$interface directory and there are two lines for that and then the rrd:ping (gateway graph) and rrd:entropy (conntrack graph) entries need to both be changed to rrd:value.
> 
> I also added the migrate-4-5 script into backup.pl
> 
> Tested all above out on my vm testbed. Fresh install of IPFire gave the new names and directories as required and everything worked. I also then restored an older backup that had the old names etc and the code in backup.pl also worked without any hitch. The graphs all worked.
> 
> The only thing I haven't done yet is adding the migrate code I put into backup.pl into the update.sh script. I will do that when next is updated to become CU191.
> 
> I will also just confirm that with the new collectd is happy to build with autoconf-2.72. Everything I have done so far is with the existing autoconf-2.71.
> 
> I think that the collectd update should be good to go into Core Update 192 early in the new year.
> 
> Regards,
> 
> Adolf.
> 
>> 
>> Regards,
>> 
>> Adolf.
>> 
>>> Regards,
>>> 
>>> Adolf
>>> 
>>>> 
>>>> If we can then run the migration script on existing systems we might almost be there…
>>>> 
>>>> -Michael
>>>> 
>>>>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> On 20/11/2024 19:25, Michael Tremer wrote:
>>>>>> Let’s 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. Let’s see…
>>>>>> 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.
>>>>> 
>>>>> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
>>>>> 
>>>>> Unfortunately it failed to build and had the following error message
>>>>> 
>>>>> 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 to.
>>>>> If you have problems, you may need to regenerate the build system entirely.
>>>>> To do so, use the procedure documented by the package, typically `autoreconf'.
>>>>> 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
>>>>> 
>>>>>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
>>>>> 
>>>>> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf.
>>>>> 
>>>>>> Best,
>>>>>> -Michael
>>>>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>> Hi Michael,
>>>>>>> 
>>>>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Adolf.
>>>>>>> 
>>>>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>>>>> Hi Michael,
>>>>>>>> 
>>>>>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>>>>> 18707     CC=""
>>>>>>>> 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 with host triplet" >&2;}
>>>>>>>> 18714 ac_tool_warned=yes ;;
>>>>>>>> 18715 esac
>>>>>>>> 18716     CC=$ac_ct_CC
>>>>>>>> 18717   fi
>>>>>>>> 18718 else
>>>>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>>>>> 18720 fi
>>>>>>>> 
>>>>>>>> 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 command
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Adolf.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119 
>>>>>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>>>>>>     Specifically, compilers that *only* implement the original “K&R”
>>>>>>>>>>     function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>>>>>     C 1989.
>>>>>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>>>> 
>>>> 
>>> 
> 
> -- 
> Sent from my laptop

Re: Failure building collectd when autoconf has been updated to 2.72

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 13795 bytes --]

Hi Michael,

On 03/12/2024 18:44, Michael Tremer wrote:
> Okay, this sounds really good then and seems to be a lot easier than expected.
> 
> Are there any changes we would like to make to the graphs in this step? Remove? Add new things?

It does seem much easier than expected. Based on that, my preference 
would be to just do the collectd version change and make sure that 
everything is really as easy as I have thought. Then we can look at any 
further changes or additions to graphs at that point.

Regards,

Adolf.

> 
>> On 29 Nov 2024, at 19:24, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi Michael,
>>
>>
>> On 25/11/2024 19:25, Adolf Belka wrote:
>>> Hi Michael,
>>>
>>> On 23/11/2024 13:09, Adolf Belka wrote:
>>>> Hi Michael,
>>>>
>>>> On 23/11/2024 10:12, Michael Tremer wrote:
>>>>> 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’t be much easier.
>>>>>
>>>>> There is a migration script here:
>>>>>
>>>>> https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108
>>>>>
>>>>> Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?
>>>>
>>>> I will give that a go and see what happens and we can work from there.
>>>>
>>> I gave it a go and have been very successful.
>>>
>>> Building the collectd-5.12.0 did result in various build failures. I think I had to do around 7 build attempts but I progressively moved forward and eventually succeeded in a successful build of the new collectd and then the rest of the IPFire build.
>>>
>>> I then installed the CU190 iso with collectd-5.12.0 into a vm system. The fresh install already updates all the rrd files with the updated changes from 4.x to 5.x
>>>
>>> There were a range of graphs that failed due to, for example, a DS named ping not being found in the ping rrd file.
>>>
>>> Checking the ping rrd file with rrdtool info I found that in 5.x the ping rrd file DS is now "value" in place of "ping".
>>>
>>> I then found the DEF statement in graphs.pl for the ping graph and changed the rrd:ping section to rrd:value and the graph started operating and collecting data. I also did it with the conntrack entry which changed from "entropy" to "value" and again the graph started working.
>>>
>>> So I know now what I need to do - find all the places where the DS has changed in an rrd file and correct those in the IPFire code.
>>>
>>> I tested out the migrate-4-5.px file and in its first phase it creates a script which will update the DS values to their new versions. I can use the output of that script to identify which files have got a change in them, find where in the code that file is accessed and modify it.
>>>
>>> We will also need to use the migrate script in the restore portion of the backup process as the rrd files are in the backup and restoring them will give files with a DS of "ping" for the ping rrd one, which will not be recognised with the modified DS values in graphs.pl etc.
>>>
>>> Running the migrate script after doing a restore will convert all the DS values to their 5.x values. If the entries in the backup are already updated then the rrdtool tune command run by the migrate script will give the error message
>>>
>>> ERROR: unknown data source name 'ping'
>>>
>>> in the example of the ping rrd file but in that case the entry is left as it is so the migrate script should be able to work on restores with the 4.x and 5.x rrd values.
>>>
>>> It looks like both DS names and DS types have been changed for some of the plugins.
>>>
>>>
>>> Anyway, things are looking very promising. Should be able to look at testing this out in unstable early in the new year.
>>>
>> So it turned out to be much easier than any of us thought. The changes needed in graphs.pl are only 4 lines to be changed.
>> The interface directory becomes the interface-$interface directory and there are two lines for that and then the rrd:ping (gateway graph) and rrd:entropy (conntrack graph) entries need to both be changed to rrd:value.
>>
>> I also added the migrate-4-5 script into backup.pl
>>
>> Tested all above out on my vm testbed. Fresh install of IPFire gave the new names and directories as required and everything worked. I also then restored an older backup that had the old names etc and the code in backup.pl also worked without any hitch. The graphs all worked.
>>
>> The only thing I haven't done yet is adding the migrate code I put into backup.pl into the update.sh script. I will do that when next is updated to become CU191.
>>
>> I will also just confirm that with the new collectd is happy to build with autoconf-2.72. Everything I have done so far is with the existing autoconf-2.71.
>>
>> I think that the collectd update should be good to go into Core Update 192 early in the new year.
>>
>> Regards,
>>
>> Adolf.
>>
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>>> Regards,
>>>>
>>>> Adolf
>>>>
>>>>>
>>>>> If we can then run the migration script on existing systems we might almost be there…
>>>>>
>>>>> -Michael
>>>>>
>>>>>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>
>>>>>> Hi Michael,
>>>>>>
>>>>>> On 20/11/2024 19:25, Michael Tremer wrote:
>>>>>>> Let’s 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. Let’s see…
>>>>>>> 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.
>>>>>>
>>>>>> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
>>>>>>
>>>>>> Unfortunately it failed to build and had the following error message
>>>>>>
>>>>>> 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 to.
>>>>>> If you have problems, you may need to regenerate the build system entirely.
>>>>>> To do so, use the procedure documented by the package, typically `autoreconf'.
>>>>>> 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
>>>>>>
>>>>>>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
>>>>>>
>>>>>> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Adolf.
>>>>>>
>>>>>>> Best,
>>>>>>> -Michael
>>>>>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>> Hi Michael,
>>>>>>>>
>>>>>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Adolf.
>>>>>>>>
>>>>>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>>>>>> 18707     CC=""
>>>>>>>>> 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 with host triplet" >&2;}
>>>>>>>>> 18714 ac_tool_warned=yes ;;
>>>>>>>>> 18715 esac
>>>>>>>>> 18716     CC=$ac_ct_CC
>>>>>>>>> 18717   fi
>>>>>>>>> 18718 else
>>>>>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>>>>>> 18720 fi
>>>>>>>>>
>>>>>>>>> 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 command
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Adolf.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>>>>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>>>>>>      Configure scripts no longer support pre-1989 C compilers.
>>>>>>>>>>>      Specifically, compilers that *only* implement the original “K&R”
>>>>>>>>>>>      function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>>>>>>      C 1989.
>>>>>>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>>>>>
>>>>>
>>>>
>>
>> -- 
>> Sent from my laptop
> 
> 

-- 
Sent from my laptop

Re: Failure building collectd when autoconf has been updated to 2.72

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 14545 bytes --]

Okay, just to recap from yesterday’s call:

We are going to migrate to collectd 5 first and ship it as soon as possible, but only whenever it is ready

We might want to check how collectd 6 is coming along, but it seems that there is nothing new in it that we would benefit from.

Maybe we have some time to tidy up the graphs and maybe there are some new, useful plugins.

-Michael

> On 3 Dec 2024, at 18:43, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 03/12/2024 18:44, Michael Tremer wrote:
>> Okay, this sounds really good then and seems to be a lot easier than expected.
>> Are there any changes we would like to make to the graphs in this step? Remove? Add new things?
> 
> It does seem much easier than expected. Based on that, my preference would be to just do the collectd version change and make sure that everything is really as easy as I have thought. Then we can look at any further changes or additions to graphs at that point.
> 
> Regards,
> 
> Adolf.
> 
>>> On 29 Nov 2024, at 19:24, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> 
>>> On 25/11/2024 19:25, Adolf Belka wrote:
>>>> Hi Michael,
>>>> 
>>>> On 23/11/2024 13:09, Adolf Belka wrote:
>>>>> Hi Michael,
>>>>> 
>>>>> On 23/11/2024 10:12, Michael Tremer wrote:
>>>>>> 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’t be much easier.
>>>>>> 
>>>>>> There is a migration script here:
>>>>>> 
>>>>>> https://github.com/collectd/collectd/blob/db4a13bdf37b1103c2014261458323e26b034eec/contrib/migrate-4-5.px#L107-L108
>>>>>> 
>>>>>> Should we maybe start with building a new branch with the latest version of collectd 5 and simply check if a newly installed system is still working? I don’t think there will be that many changes required. Would you be up for giving that a go?
>>>>> 
>>>>> I will give that a go and see what happens and we can work from there.
>>>>> 
>>>> I gave it a go and have been very successful.
>>>> 
>>>> Building the collectd-5.12.0 did result in various build failures. I think I had to do around 7 build attempts but I progressively moved forward and eventually succeeded in a successful build of the new collectd and then the rest of the IPFire build.
>>>> 
>>>> I then installed the CU190 iso with collectd-5.12.0 into a vm system. The fresh install already updates all the rrd files with the updated changes from 4.x to 5.x
>>>> 
>>>> There were a range of graphs that failed due to, for example, a DS named ping not being found in the ping rrd file.
>>>> 
>>>> Checking the ping rrd file with rrdtool info I found that in 5.x the ping rrd file DS is now "value" in place of "ping".
>>>> 
>>>> I then found the DEF statement in graphs.pl for the ping graph and changed the rrd:ping section to rrd:value and the graph started operating and collecting data. I also did it with the conntrack entry which changed from "entropy" to "value" and again the graph started working.
>>>> 
>>>> So I know now what I need to do - find all the places where the DS has changed in an rrd file and correct those in the IPFire code.
>>>> 
>>>> I tested out the migrate-4-5.px file and in its first phase it creates a script which will update the DS values to their new versions. I can use the output of that script to identify which files have got a change in them, find where in the code that file is accessed and modify it.
>>>> 
>>>> We will also need to use the migrate script in the restore portion of the backup process as the rrd files are in the backup and restoring them will give files with a DS of "ping" for the ping rrd one, which will not be recognised with the modified DS values in graphs.pl etc.
>>>> 
>>>> Running the migrate script after doing a restore will convert all the DS values to their 5.x values. If the entries in the backup are already updated then the rrdtool tune command run by the migrate script will give the error message
>>>> 
>>>> ERROR: unknown data source name 'ping'
>>>> 
>>>> in the example of the ping rrd file but in that case the entry is left as it is so the migrate script should be able to work on restores with the 4.x and 5.x rrd values.
>>>> 
>>>> It looks like both DS names and DS types have been changed for some of the plugins.
>>>> 
>>>> 
>>>> Anyway, things are looking very promising. Should be able to look at testing this out in unstable early in the new year.
>>>> 
>>> So it turned out to be much easier than any of us thought. The changes needed in graphs.pl are only 4 lines to be changed.
>>> The interface directory becomes the interface-$interface directory and there are two lines for that and then the rrd:ping (gateway graph) and rrd:entropy (conntrack graph) entries need to both be changed to rrd:value.
>>> 
>>> I also added the migrate-4-5 script into backup.pl
>>> 
>>> Tested all above out on my vm testbed. Fresh install of IPFire gave the new names and directories as required and everything worked. I also then restored an older backup that had the old names etc and the code in backup.pl also worked without any hitch. The graphs all worked.
>>> 
>>> The only thing I haven't done yet is adding the migrate code I put into backup.pl into the update.sh script. I will do that when next is updated to become CU191.
>>> 
>>> I will also just confirm that with the new collectd is happy to build with autoconf-2.72. Everything I have done so far is with the existing autoconf-2.71.
>>> 
>>> I think that the collectd update should be good to go into Core Update 192 early in the new year.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.
>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf
>>>>> 
>>>>>> 
>>>>>> If we can then run the migration script on existing systems we might almost be there…
>>>>>> 
>>>>>> -Michael
>>>>>> 
>>>>>>> On 22 Nov 2024, at 18:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>> 
>>>>>>> Hi Michael,
>>>>>>> 
>>>>>>> On 20/11/2024 19:25, Michael Tremer wrote:
>>>>>>>> Let’s 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. Let’s see…
>>>>>>>> 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.
>>>>>>> 
>>>>>>> I removed the two patches and also removed the two autoreconf commands, leaving the autoupdate command in place.
>>>>>>> 
>>>>>>> Unfortunately it failed to build and had the following error message
>>>>>>> 
>>>>>>> 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 to.
>>>>>>> If you have problems, you may need to regenerate the build system entirely.
>>>>>>> To do so, use the procedure documented by the package, typically `autoreconf'.
>>>>>>> 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
>>>>>>> 
>>>>>>>> I can’t remember what has stopped us from moving with upstream apart from the RRD file format. If this all doesn’t work, maybe we should look at this all again and see if we can’t migrate to the latest upstream version again.
>>>>>>> 
>>>>>>> As far as I can remember it was mentioned that the issue was the changed format and RRD being used in so many places making the update require changes in so many places in IPFire-2.x
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Adolf.
>>>>>>> 
>>>>>>>> Best,
>>>>>>>> -Michael
>>>>>>>>> On 19 Nov 2024, at 13:55, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>>>>>>> Hi Michael,
>>>>>>>>> 
>>>>>>>>> Also reran the collectd autoreconf with the autoconf-2.71 and in that case 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 is the one with a missing ), all the rest have a yes:) entry.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> Adolf.
>>>>>>>>> 
>>>>>>>>>> On 19/11/2024 14:43, Adolf Belka wrote:
>>>>>>>>>> Hi Michael,
>>>>>>>>>> 
>>>>>>>>>> I obtained the configure created by the autoreconf etc and I have found the error. Here is the affected line 18710
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 18706   if test "x$ac_ct_CC" = x; then
>>>>>>>>>> 18707     CC=""
>>>>>>>>>> 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 with host triplet" >&2;}
>>>>>>>>>> 18714 ac_tool_warned=yes ;;
>>>>>>>>>> 18715 esac
>>>>>>>>>> 18716     CC=$ac_ct_CC
>>>>>>>>>> 18717   fi
>>>>>>>>>> 18718 else
>>>>>>>>>> 18719   CC="$ac_cv_prog_CC"
>>>>>>>>>> 18720 fi
>>>>>>>>>> 
>>>>>>>>>> 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 command
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Adolf.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 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=ipfire-2.x.git;a=blob;f=lfs/collectd;h=d1d4ea721386803c31599315de956373417c2dcf;hb=HEAD#l119
>>>>>>>>>>> Is there any output of that command? There should be some warnings which might 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:
>>>>>>>>>>>> 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=`$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"\" = 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="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 for 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 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 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 configure scripts will continue working. The one that doesn't mention that is the following change:-
>>>>>>>>>>>>     Configure scripts no longer support pre-1989 C compilers.
>>>>>>>>>>>>     Specifically, compilers that *only* implement the original “K&R”
>>>>>>>>>>>>     function definition syntax, and not the newer “prototyped” 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 “C23”), 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’t implement a core feature of
>>>>>>>>>>>>     C 1989.
>>>>>>>>>>>> However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe 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 aspect 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.
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> -- 
>>> Sent from my laptop
> 
> -- 
> Sent from my laptop