GNU bug report logs - #70944
uninitialized variable used in libtoolize, function func_serial_update

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70944 in the body.
You can then email your comments to 70944 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-libtool <at> gnu.org
Subject: uninitialized variable used in libtoolize, function func_serial_update
Date: Tue, 14 May 2024 17:42:45 +0200

[Message part 1 (text/plain, inline)]

Hi,

I'm building libtool from the git repository, as follows:

rm -f .gitmodules
date --utc --iso-8601 > .tarball-version
./bootstrap --no-git --gnulib-srcdir="$GNULIB_SRCDIR"
./configure --config-cache CPPFLAGS="-Wall"
make
make check TESTSUITEFLAGS="--debug"

and I see a failure of test 13:

 13: upgrading verbatim style aclocal.m4             FAILED (libtoolize.at:691)

testsuite.dir/013/testsuite.log contains this diff:

--- expout	2024-05-14 11:34:43.166241683 +0000
+++ /home/runner/work/ci-check/ci-check/libtool/tests/testsuite.dir/at-groups/13/stdout	2024-05-14 11:34:43.326241473 +0000
@@ -1,5 +1,6 @@
 libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
 libtoolize: copying file 'm4/libtool.m4'
+libtoolize: You should add the contents of 'm4/libtool.m4' to 'aclocal.m4'.
 libtoolize: copying file 'm4/ltoptions.m4'
 libtoolize: copying file 'm4/ltsugar.m4'
 libtoolize: You should add the contents of 'm4/ltsugar.m4' to 'aclocal.m4'.
13. libtoolize.at:624: 13. upgrading verbatim style aclocal.m4 (libtoolize.at:624): FAILED (libtoolize.at:691)

Why is this line "You should add the contents of 'm4/libtool.m4' to 'aclocal.m4'."
printed?

It's because in function func_serial_update, the value of my_src_serial is
used, which has not been set in this function, but in a completely different
function.

Namely, first, func_serial_update_check is called, which performs the
assignments

  my_srcfile=/LIBTOOL/libtool/build-aux/ltmain.sh
  my_src_serial=2024

based on a sed script that extracts the package_revision of build-aux/ltmain.sh,
which in my case has in line 5:

  # libtool (GNU libtool) 2024-05-14

Then, later, in function func_serial_update, my_src_serial still has the old
value. The parameters of this invocation are:

  my_filename=libtool.m4
  my_srcdir=/LIBTOOL/libtool/m4
  my_destdir=m4
  my_msg_var=my_pkgmacro_header
  my_macro_regex=LT_INIT
  my_old_macro_regex='A[CM]_PROG_LIBTOOL'
  my_serial_update_p=:

  my_srcfile=/LIBTOOL/libtool/m4/libtool.m4
  my_destfile=m4/libtool.m4

The block

  if test -f "$my_destfile"; then
    ...
  fi

is skipped, because $my_destfile does not yet exist. Then

  my_included_files=aclocal.m4

and

  func_serial_max 2024 25

Thus it uses the "serial version" 2024 of ltmain.sh and compares it to
the serial version 25 of aclocal.m4.

This is obviously buggy. It makes no sense to compare the serial number
of two unrelated files (ltmain.sh and aclocal.m4).

The attached patch fixes it for me.

[0001-libtoolize-Don-t-use-uninitialized-variable.patch (text/x-patch, attachment)]

Message #10 received at 70944-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 70944-done <at> debbugs.gnu.org
Cc: Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#70944: uninitialized variable used in libtoolize, function
 func_serial_update
Date: Mon, 1 Jul 2024 18:59:01 +0300

[Message part 1 (text/plain, inline)]

On 14/05/2024 18:42, Bruno Haible wrote:
> Hi,
> 
> I'm building libtool from the git repository, as follows:
> 
> rm -f .gitmodules
> date --utc --iso-8601 > .tarball-version
> ./bootstrap --no-git --gnulib-srcdir="$GNULIB_SRCDIR"
> ./configure --config-cache CPPFLAGS="-Wall"
> make
> make check TESTSUITEFLAGS="--debug"
> 
> and I see a failure of test 13:
> 
>   13: upgrading verbatim style aclocal.m4             FAILED (libtoolize.at:691)
> 
> testsuite.dir/013/testsuite.log contains this diff:
> 
> --- expout	2024-05-14 11:34:43.166241683 +0000
> +++ /home/runner/work/ci-check/ci-check/libtool/tests/testsuite.dir/at-groups/13/stdout	2024-05-14 11:34:43.326241473 +0000
> @@ -1,5 +1,6 @@
>   libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
>   libtoolize: copying file 'm4/libtool.m4'
> +libtoolize: You should add the contents of 'm4/libtool.m4' to 'aclocal.m4'.
>   libtoolize: copying file 'm4/ltoptions.m4'
>   libtoolize: copying file 'm4/ltsugar.m4'
>   libtoolize: You should add the contents of 'm4/ltsugar.m4' to 'aclocal.m4'.
> 13. libtoolize.at:624: 13. upgrading verbatim style aclocal.m4 (libtoolize.at:624): FAILED (libtoolize.at:691)
> 
> Why is this line "You should add the contents of 'm4/libtool.m4' to 'aclocal.m4'."
> printed?
> 
> It's because in function func_serial_update, the value of my_src_serial is
> used, which has not been set in this function, but in a completely different
> function.
> 
> Namely, first, func_serial_update_check is called, which performs the
> assignments
> 
>    my_srcfile=/LIBTOOL/libtool/build-aux/ltmain.sh
>    my_src_serial=2024
> 
> based on a sed script that extracts the package_revision of build-aux/ltmain.sh,
> which in my case has in line 5:
> 
>    # libtool (GNU libtool) 2024-05-14
> 
> Then, later, in function func_serial_update, my_src_serial still has the old
> value. The parameters of this invocation are:
> 
>    my_filename=libtool.m4
>    my_srcdir=/LIBTOOL/libtool/m4
>    my_destdir=m4
>    my_msg_var=my_pkgmacro_header
>    my_macro_regex=LT_INIT
>    my_old_macro_regex='A[CM]_PROG_LIBTOOL'
>    my_serial_update_p=:
> 
>    my_srcfile=/LIBTOOL/libtool/m4/libtool.m4
>    my_destfile=m4/libtool.m4
> 
> The block
> 
>    if test -f "$my_destfile"; then
>      ...
>    fi
> 
> is skipped, because $my_destfile does not yet exist. Then
> 
>    my_included_files=aclocal.m4
> 
> and
> 
>    func_serial_max 2024 25
> 
> Thus it uses the "serial version" 2024 of ltmain.sh and compares it to
> the serial version 25 of aclocal.m4.
> 
> This is obviously buggy. It makes no sense to compare the serial number
> of two unrelated files (ltmain.sh and aclocal.m4).
> 
> The attached patch fixes it for me.
> 

Thank you for the patch. It has been applied in libtool:

https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=67c5a06a468be0fe4dc172d308857619d71b5d90

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.