[PATCH][ding-libs] SPEC: Do not call autoreconf on epel5

[Lukas Slebodnik]

ehlo,

There is a bug in old version of autotools which cause compilation problems

./libtool: line 1161: X-c: command not found
./libtool: line 1213: Xpath_utils/path_utils.lo: No such file or directory
./libtool: line 1218: libtool: compile: cannot determine name of library object
from `': command not found
make[1]: *** [path_utils/path_utils.lo] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/ding-libs-0.4.0'

I used this patch for building ding-libs in copr [1] but I forgot to send
patch to upstream.

LS

[1] https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> ehlo,
>
> There is a bug in old version of autotools which cause compilation
> problems
>
> ./libtool: line 1161: X-c: command not found ./libtool: line 1213:
> Xpath_utils/path_utils.lo: No such file or directory ./libtool:
> line 1218: libtool: compile: cannot determine name of library
> object from `': command not found make[1]: ***
> [path_utils/path_utils.lo] Error 1 make[1]: Leaving directory
> `/builddir/build/BUILD/ding-libs-0.4.0'
>
> I used this patch for building ding-libs in copr [1] but I forgot
> to send patch to upstream.
>
> LS
>
> [1] https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/

Nack. It's always better to perform the autoreconf properly. We hit
this same bug back in 2011 with SSSD[1]. I just performed a scratch
build with the attached patch[2] which worked successfully.

[1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in the SSSD git
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO7OacACgkQeiVVYja6o6PYwwCgoavWN+B+sI1MejCE3twXL0xN
> zdQAnAh0vTyRjqIdt3tk6qSDHGv/xa6i
> =GP2r
> -----END PGP SIGNATURE-----

[Lukas Slebodnik]

On (07/07/14 20:22), Stephen Gallagher wrote:
> On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> > ehlo,
> >
> > There is a bug in old version of autotools which cause compilation
> > problems
> >
> > ./libtool: line 1161: X-c: command not found ./libtool: line 1213:
> > Xpath_utils/path_utils.lo: No such file or directory ./libtool:
> > line 1218: libtool: compile: cannot determine name of library
> > object from `': command not found make[1]: ***
> > [path_utils/path_utils.lo] Error 1 make[1]: Leaving directory
> > `/builddir/build/BUILD/ding-libs-0.4.0'
> >
> > I used this patch for building ding-libs in copr [1] but I forgot
> > to send patch to upstream.
> >
> > LS
> >
> > [1] https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
>
> Nack. It's always better to perform the autoreconf properly. We hit
> this same bug back in 2011 with SSSD[1]. I just performed a scratch
> build with the attached patch[2] which worked successfully.
>
> [1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in the SSSD git
> [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> From f31135f1abc3d856d9a5818b1a60dbb8414a6e5d Mon Sep 17 00:00:00 2001
> From: Stephen Gallagher 
> Date: Mon, 7 Jul 2014 20:14:36 -0400
> Subject: [PATCH] Fix specfile for RHEL5
>
> RHEL5 uses an old libtool. We need to forcibly remove certain m4
> files before running autoreconf to ensure that they get replaced
> with the appropriate old versions.
>
> contrib/ding-libs.spec.in | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/contrib/ding-libs.spec.in b/contrib/ding-libs.spec.in
> index 87f2a1ab915c2225f0a2b83a1de1d2980489e210..30d6775401f42f565de0aef0cfa179cd9dc38e74 100644
> --- a/contrib/ding-libs.spec.in
> +++ b/contrib/ding-libs.spec.in
> @@ -324,7 +324,17 @@ structure
> %setup -q
>
> %build
>
> +# RHEL 5 uses an old libtool, so we need to force it to reconfigure
> +# This is safe to do on newer packages too, as it will just
> +# gather the appropriate m4 files from the libtool package

This explanation is not right. The problem is not with libtool but with buggy
version of autoreconf on RHEL5.

bash-3.2# autoreconf -if
  You should update your `aclocal.m4' by running aclocal.
  Putting files in AC_CONFIG_AUX_DIR, `build'.
  Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or
  Makefile.am:259: library has `EXTRA_libini_config_la' as canonic name (possible typo)

As you can see there is a warning:
    "You should update your `aclocal.m4' by running aclocal."

Warnings "EXTRA_*" are irrelevant in this case.

man autoreconf says:
       Run  `autoconf'  (and  `autoheader', `aclocal', `automake', `autopoint'
       (formerly `gettextize'), and `libtoolize' where appropriate) repeatedly
       to  remake  the GNU Build System files in the DIRECTORIES or the direc‐
       tory trees driven by CONFIGURE-AC (defaulting to `.').

So aclocal should be executed by autoreconf itself.
> +for i in libtool.m4  lt~obsolete.m4  ltoptions.m4  ltsugar.m4  ltversion.m4
> +do
> find . -name $i -exec rm -f {} ;
>
> +done
>
> autoreconf -ivf
>
> %configure \
>     --disable-static

I would prefer to either run "aclocal" after autoreconf or remove all files
from directory m4 (rm -rf m4/* 2>/dev/null). For loop is a kind of hack,
because we know that all files will be stored in directory m4.
    AC_CONFIG_MACRO_DIR([m4])

LS

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/10/2014 05:46 AM, Lukas Slebodnik wrote:
> On (07/07/14 20:22), Stephen Gallagher wrote:
> > On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> > > ehlo,
> > >
> > > There is a bug in old version of autotools which cause
> > > compilation problems
> > >
> > > ./libtool: line 1161: X-c: command not found ./libtool: line
> > > 1213: Xpath_utils/path_utils.lo: No such file or directory
> > > ./libtool: line 1218: libtool: compile: cannot determine name
> > > of library object from `': command not found make[1]: *** 
> > > [path_utils/path_utils.lo] Error 1 make[1]: Leaving directory 
> > > `/builddir/build/BUILD/ding-libs-0.4.0'
> > >
> > > I used this patch for building ding-libs in copr [1] but I
> > > forgot to send patch to upstream.
> > >
> > > LS
> > >
> > > [1] https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
> >
> > Nack. It's always better to perform the autoreconf properly. We
> > hit this same bug back in 2011 with SSSD[1]. I just performed a
> > scratch build with the attached patch[2] which worked
> > successfully.
> >
> > [1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in the
> > SSSD git [2]
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> > From f31135f1abc3d856d9a5818b1a60dbb8414a6e5d Mon Sep 17 00:00:00
> > 2001 From: Stephen Gallagher  Date: Mon, 7
> > Jul 2014 20:14:36 -0400 Subject: [PATCH] Fix specfile for RHEL5
> >
> > RHEL5 uses an old libtool. We need to forcibly remove certain m4 
> > files before running autoreconf to ensure that they get replaced 
> > with the appropriate old versions. --- contrib/ding-libs.spec.in
> > | 10 ++++++++++ 1 file changed, 10 insertions(+)
> >
> > diff --git a/contrib/ding-libs.spec.in
> > b/contrib/ding-libs.spec.in index
> > 87f2a1ab915c2225f0a2b83a1de1d2980489e210..30d6775401f42f565de0aef0cfa179cd9dc38e74
> > 100644 --- a/contrib/ding-libs.spec.in +++
> > b/contrib/ding-libs.spec.in @@ -324,7 +324,17 @@ structure %setup
> > -q
> >
> > %build + +# RHEL 5 uses an old libtool, so we need to force it to
> > reconfigure +# This is safe to do on newer packages too, as it
> > will just +# gather the appropriate m4 files from the libtool
> > package
>
> This explanation is not right. The problem is not with libtool but
> with buggy version of autoreconf on RHEL5.
>
> bash-3.2# autoreconf -if You should update your `aclocal.m4' by
> running aclocal. Putting files in AC_CONFIG_AUX_DIR, `build'. 
> Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is
> defined but no program or Makefile.am:259: library has
> `EXTRA_libini_config_la' as canonic name (possible typo)
>
> As you can see there is a warning: "You should update your
> `aclocal.m4' by running aclocal."
>
> Warnings "EXTRA_*" are irrelevant in this case.
>
> man autoreconf says: Run  `autoconf'  (and  `autoheader',
> `aclocal', `automake', `autopoint' (formerly `gettextize'), and
> `libtoolize' where appropriate) repeatedly to  remake  the GNU
> Build System files in the DIRECTORIES or the direc‐ tory trees
> driven by CONFIGURE-AC (defaulting to `.').
>
> So aclocal should be executed by autoreconf itself.
> > +for i in libtool.m4  lt~obsolete.m4  ltoptions.m4  ltsugar.m4
> > ltversion.m4 +do +    find . -name $i -exec rm -f {} ; +done + 
> > autoreconf -ivf + %configure \ --disable-static
>
> I would prefer to either run "aclocal" after autoreconf or remove
> all files from directory m4 (rm -rf m4/* 2>/dev/null). For loop is
> a kind of hack, because we know that all files will be stored in
> directory m4. AC_CONFIG_MACRO_DIR([m4])

My major concern is that we really do need to be running autoreconf on
all platforms, because it's the only way we can be sure to pick up any
distro-specific changes that have been made to the autotools (like
some of the recent security patches in Fedora). If we don't regenerate
things like libtool, then SSSD isn't taking advantage of them.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO+qIcACgkQeiVVYja6o6MgaQCfT1wDOhHf8Z0c0Y9GCXpccamI
> Y2sAn2B2S04zHk9cvDRXHn82zI+dreyA
> =ofZ8
> -----END PGP SIGNATURE-----

[Lukas Slebodnik]

On (10/07/14 10:51), Stephen Gallagher wrote:
> On 07/10/2014 05:46 AM, Lukas Slebodnik wrote:
> > On (07/07/14 20:22), Stephen Gallagher wrote:
> > > On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> > > > ehlo,
> > > >
> > > > There is a bug in old version of autotools which cause
> > > > compilation problems
> > > >
> > > > ./libtool: line 1161: X-c: command not found ./libtool: line
> > > > 1213: Xpath_utils/path_utils.lo: No such file or directory
> > > > ./libtool: line 1218: libtool: compile: cannot determine name
> > > > of library object from `': command not found make[1]: *** 
> > > > [path_utils/path_utils.lo] Error 1 make[1]: Leaving directory 
> > > > `/builddir/build/BUILD/ding-libs-0.4.0'
> > > >
> > > > I used this patch for building ding-libs in copr [1] but I
> > > > forgot to send patch to upstream.
> > > >
> > > > LS
> > > >
> > > > [1] https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
> > >
> > > Nack. It's always better to perform the autoreconf properly. We
> > > hit this same bug back in 2011 with SSSD[1]. I just performed a
> > > scratch build with the attached patch[2] which worked
> > > successfully.
> > >
> > > [1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in the
> > > SSSD git [2]
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> > > From f31135f1abc3d856d9a5818b1a60dbb8414a6e5d Mon Sep 17 00:00:00
> > > 2001 From: Stephen Gallagher  Date: Mon, 7
> > > Jul 2014 20:14:36 -0400 Subject: [PATCH] Fix specfile for RHEL5
> > >
> > > RHEL5 uses an old libtool. We need to forcibly remove certain m4 
> > > files before running autoreconf to ensure that they get replaced 
> > > with the appropriate old versions. --- contrib/ding-libs.spec.in
> > > | 10 ++++++++++ 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/contrib/ding-libs.spec.in
> > > b/contrib/ding-libs.spec.in index
> > > 87f2a1ab915c2225f0a2b83a1de1d2980489e210..30d6775401f42f565de0aef0cfa179cd9dc38e74
> > > 100644 --- a/contrib/ding-libs.spec.in +++
> > > b/contrib/ding-libs.spec.in @@ -324,7 +324,17 @@ structure %setup
> > > -q
> > >
> > > %build + +# RHEL 5 uses an old libtool, so we need to force it to
> > > reconfigure +# This is safe to do on newer packages too, as it
> > > will just +# gather the appropriate m4 files from the libtool
> > > package
> >
> > This explanation is not right. The problem is not with libtool but
> > with buggy version of autoreconf on RHEL5.
> >
> > bash-3.2# autoreconf -if You should update your `aclocal.m4' by
> > running aclocal. Putting files in AC_CONFIG_AUX_DIR, `build'. 
> > Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is
> > defined but no program or Makefile.am:259: library has
> > `EXTRA_libini_config_la' as canonic name (possible typo)
> >
> > As you can see there is a warning: "You should update your
> > `aclocal.m4' by running aclocal."
> >
> > Warnings "EXTRA_*" are irrelevant in this case.
> >
> > man autoreconf says: Run  `autoconf'  (and  `autoheader',
> > `aclocal', `automake', `autopoint' (formerly `gettextize'), and
> > `libtoolize' where appropriate) repeatedly to  remake  the GNU
> > Build System files in the DIRECTORIES or the direc‐ tory trees
> > driven by CONFIGURE-AC (defaulting to `.').
> >
> > So aclocal should be executed by autoreconf itself.
> > > +for i in libtool.m4  lt~obsolete.m4  ltoptions.m4  ltsugar.m4
> > > ltversion.m4 +do +    find . -name $i -exec rm -f {} ; +done + 
> > > autoreconf -ivf + %configure \ --disable-static
> >
> > I would prefer to either run "aclocal" after autoreconf or remove
> > all files from directory m4 (rm -rf m4/* 2>/dev/null). For loop is
> > a kind of hack, because we know that all files will be stored in
> > directory m4. AC_CONFIG_MACRO_DIR([m4])
>
> My major concern is that we really do need to be running autoreconf on
> all platforms, because it's the only way we can be sure to pick up any
> distro-specific changes that have been made to the autotools (like
> some of the recent security patches in Fedora). If we don't regenerate
> things like libtool, then SSSD isn't taking advantage of them.

I was not against calling autoreconf in my previous mail.
But I don't like your solution with removing lt*.m4 files. I proposed two
solutions.

a)
@@ -325,6 +325,9 @@ structure

%build
 autoreconf -ivf
+#nice comment with explanation problem with autoreconf on rhel5
+# bash-3.2# autoreconf -if
+# You should update your `aclocal.m4' by running aclocal.
+# Putting files in AC_CONFIG_AUX_DIR, `build'.
+aclocal
+
 %configure \
     --disable-static

b) small modification of your patch.
@@ -324,6 +324,9 @@ structure

%build
+
+#nice comment with explanation
+rm -f m4/* 2>/dev/null
 autoreconf -ivf
 %configure \
     --disable-static

LS

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/10/2014 12:24 PM, Lukas Slebodnik wrote:
> On (10/07/14 10:51), Stephen Gallagher wrote:
> > On 07/10/2014 05:46 AM, Lukas Slebodnik wrote:
> > > On (07/07/14 20:22), Stephen Gallagher wrote:
> > > > On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> > > > > ehlo,
> > > > >
> > > > > There is a bug in old version of autotools which cause 
> > > > > compilation problems
> > > > >
> > > > > ./libtool: line 1161: X-c: command not found ./libtool:
> > > > > line 1213: Xpath_utils/path_utils.lo: No such file or
> > > > > directory ./libtool: line 1218: libtool: compile: cannot
> > > > > determine name of library object from `': command not found
> > > > > make[1]: *** [path_utils/path_utils.lo] Error 1 make[1]:
> > > > > Leaving directory `/builddir/build/BUILD/ding-libs-0.4.0'
> > > > >
> > > > > I used this patch for building ding-libs in copr [1] but I 
> > > > > forgot to send patch to upstream.
> > > > >
> > > > > LS
> > > > >
> > > > > [1]
> > > > > https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
> > > >
> > > > Nack. It's always better to perform the autoreconf properly.
> > > > We hit this same bug back in 2011 with SSSD[1]. I just
> > > > performed a scratch build with the attached patch[2] which
> > > > worked successfully.
> > > >
> > > > [1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in
> > > > the SSSD git [2] 
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> > > > From f31135f1abc3d856d9a5818b1a60dbb8414a6e5d Mon Sep 17
> > > > 00:00:00 2001 From: Stephen Gallagher 
> > > > Date: Mon, 7 Jul 2014 20:14:36 -0400 Subject: [PATCH] Fix
> > > > specfile for RHEL5
> > > >
> > > > RHEL5 uses an old libtool. We need to forcibly remove certain
> > > > m4 files before running autoreconf to ensure that they get
> > > > replaced with the appropriate old versions. ---
> > > > contrib/ding-libs.spec.in | 10 ++++++++++ 1 file changed, 10
> > > > insertions(+)
> > > >
> > > > diff --git a/contrib/ding-libs.spec.in 
> > > > b/contrib/ding-libs.spec.in index 
> > > > 87f2a1ab915c2225f0a2b83a1de1d2980489e210..30d6775401f42f565de0aef0cfa179cd9dc38e74

100644 --- a/contrib/ding-libs.spec.in +++
> > > > b/contrib/ding-libs.spec.in @@ -324,7 +324,17 @@ structure
> > > > %setup -q
> > > >
> > > > %build + +# RHEL 5 uses an old libtool, so we need to force
> > > > it to reconfigure +# This is safe to do on newer packages
> > > > too, as it will just +# gather the appropriate m4 files from
> > > > the libtool package
> > >
> > > This explanation is not right. The problem is not with libtool
> > > but with buggy version of autoreconf on RHEL5.
> > >
> > > bash-3.2# autoreconf -if You should update your `aclocal.m4'
> > > by running aclocal. Putting files in AC_CONFIG_AUX_DIR,
> > > `build'. Makefile.am:259: variable
> > > `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program
> > > or Makefile.am:259: library has `EXTRA_libini_config_la' as
> > > canonic name (possible typo)
> > >
> > > As you can see there is a warning: "You should update your 
> > > `aclocal.m4' by running aclocal."
> > >
> > > Warnings "EXTRA_*" are irrelevant in this case.
> > >
> > > man autoreconf says: Run  `autoconf'  (and  `autoheader', 
> > > `aclocal', `automake', `autopoint' (formerly `gettextize'),
> > > and `libtoolize' where appropriate) repeatedly to  remake  the
> > > GNU Build System files in the DIRECTORIES or the direc‐ tory
> > > trees driven by CONFIGURE-AC (defaulting to `.').
> > >
> > > So aclocal should be executed by autoreconf itself.
> > > > +for i in libtool.m4  lt~obsolete.m4  ltoptions.m4
> > > > ltsugar.m4 ltversion.m4 +do +    find . -name $i -exec rm -f
> > > > {} ; +done + autoreconf -ivf + %configure \
> > > > --disable-static
> > >
> > > I would prefer to either run "aclocal" after autoreconf or
> > > remove all files from directory m4 (rm -rf m4/* 2>/dev/null).
> > > For loop is a kind of hack, because we know that all files will
> > > be stored in directory m4. AC_CONFIG_MACRO_DIR([m4])
> >
> > My major concern is that we really do need to be running
> > autoreconf on all platforms, because it's the only way we can be
> > sure to pick up any distro-specific changes that have been made
> > to the autotools (like some of the recent security patches in
> > Fedora). If we don't regenerate things like libtool, then SSSD
> > isn't taking advantage of them.
>
> I was not against calling autoreconf in my previous mail. But I
> don't like your solution with removing lt*.m4 files. I proposed
> two solutions.
>
> a) @@ -325,6 +325,9 @@ structure
>
> %build autoreconf -ivf +#nice comment with explanation problem with
> autoreconf on rhel5 +# bash-3.2# autoreconf -if +# You should
> update your `aclocal.m4' by running aclocal. +# Putting files in
> AC_CONFIG_AUX_DIR, `build'. +aclocal + %configure \ 
> --disable-static
>
> b) small modification of your patch. @@ -324,6 +324,9 @@ structure
>
> %build + +#nice comment with explanation +rm -f m4/* 2>/dev/null 
> autoreconf -ivf %configure \ --disable-static

I prefer option b) here. Sorry, I misunderstood your previous email.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO+wRcACgkQeiVVYja6o6NdwgCeMw4mZn86E3uV3vOk3xSgD65f
> /WcAnRg7IEWiUFmlyK4q141S+s0BtL3P
> =CEIB
> -----END PGP SIGNATURE-----

[Lukas Slebodnik]

On (10/07/14 12:36), Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/10/2014 12:24 PM, Lukas Slebodnik wrote:
> > On (10/07/14 10:51), Stephen Gallagher wrote:
> > > On 07/10/2014 05:46 AM, Lukas Slebodnik wrote:
> > > > On (07/07/14 20:22), Stephen Gallagher wrote:
> > > > > On 07/07/2014 10:05 AM, Lukas Slebodnik wrote:
> > > > > > ehlo,
> > > > > >
> > > > > > There is a bug in old version of autotools which cause 
> > > > > > compilation problems
> > > > > >
> > > > > > ./libtool: line 1161: X-c: command not found ./libtool:
> > > > > > line 1213: Xpath_utils/path_utils.lo: No such file or
> > > > > > directory ./libtool: line 1218: libtool: compile: cannot
> > > > > > determine name of library object from `': command not found
> > > > > > make[1]: *** [path_utils/path_utils.lo] Error 1 make[1]:
> > > > > > Leaving directory `/builddir/build/BUILD/ding-libs-0.4.0'
> > > > > >
> > > > > > I used this patch for building ding-libs in copr [1] but I 
> > > > > > forgot to send patch to upstream.
> > > > > >
> > > > > > LS
> > > > > >
> > > > > > [1]
> > > > > > https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
> > > > >
> > > > > Nack. It's always better to perform the autoreconf properly.
> > > > > We hit this same bug back in 2011 with SSSD[1]. I just
> > > > > performed a scratch build with the attached patch[2] which
> > > > > worked successfully.
> > > > >
> > > > > [1] Commit ID a1294c95a4f9f37bbe9a8635defa3a45e59213ab in
> > > > > the SSSD git [2] 
> > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7114910
> > > > > From f31135f1abc3d856d9a5818b1a60dbb8414a6e5d Mon Sep 17
> > > > > 00:00:00 2001 From: Stephen Gallagher 
> > > > > Date: Mon, 7 Jul 2014 20:14:36 -0400 Subject: [PATCH] Fix
> > > > > specfile for RHEL5
> > > > >
> > > > > RHEL5 uses an old libtool. We need to forcibly remove certain
> > > > > m4 files before running autoreconf to ensure that they get
> > > > > replaced with the appropriate old versions. ---
> > > > > contrib/ding-libs.spec.in | 10 ++++++++++ 1 file changed, 10
> > > > > insertions(+)
> > > > >
> > > > > diff --git a/contrib/ding-libs.spec.in 
> > > > > b/contrib/ding-libs.spec.in index 
> > > > > 87f2a1ab915c2225f0a2b83a1de1d2980489e210..30d6775401f42f565de0aef0cfa179cd9dc38e74
>
> 100644 --- a/contrib/ding-libs.spec.in +++
> > > > > b/contrib/ding-libs.spec.in @@ -324,7 +324,17 @@ structure
> > > > > %setup -q
> > > > >
> > > > > %build + +# RHEL 5 uses an old libtool, so we need to force
> > > > > it to reconfigure +# This is safe to do on newer packages
> > > > > too, as it will just +# gather the appropriate m4 files from
> > > > > the libtool package
> > > >
> > > > This explanation is not right. The problem is not with libtool
> > > > but with buggy version of autoreconf on RHEL5.
> > > >
> > > > bash-3.2# autoreconf -if You should update your `aclocal.m4'
> > > > by running aclocal. Putting files in AC_CONFIG_AUX_DIR,
> > > > `build'. Makefile.am:259: variable
> > > > `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program
> > > > or Makefile.am:259: library has `EXTRA_libini_config_la' as
> > > > canonic name (possible typo)
> > > >
> > > > As you can see there is a warning: "You should update your 
> > > > `aclocal.m4' by running aclocal."
> > > >
> > > > Warnings "EXTRA_*" are irrelevant in this case.
> > > >
> > > > man autoreconf says: Run  `autoconf'  (and  `autoheader', 
> > > > `aclocal', `automake', `autopoint' (formerly `gettextize'),
> > > > and `libtoolize' where appropriate) repeatedly to  remake  the
> > > > GNU Build System files in the DIRECTORIES or the direc‐ tory
> > > > trees driven by CONFIGURE-AC (defaulting to `.').
> > > >
> > > > So aclocal should be executed by autoreconf itself.
> > > > > +for i in libtool.m4  lt~obsolete.m4  ltoptions.m4
> > > > > ltsugar.m4 ltversion.m4 +do +    find . -name $i -exec rm -f
> > > > > {} ; +done + autoreconf -ivf + %configure \
> > > > > --disable-static
> > > >
> > > > I would prefer to either run "aclocal" after autoreconf or
> > > > remove all files from directory m4 (rm -rf m4/* 2>/dev/null).
> > > > For loop is a kind of hack, because we know that all files will
> > > > be stored in directory m4. AC_CONFIG_MACRO_DIR([m4])
> > >
> > > My major concern is that we really do need to be running
> > > autoreconf on all platforms, because it's the only way we can be
> > > sure to pick up any distro-specific changes that have been made
> > > to the autotools (like some of the recent security patches in
> > > Fedora). If we don't regenerate things like libtool, then SSSD
> > > isn't taking advantage of them.
> >
> > I was not against calling autoreconf in my previous mail. But I
> > don't like your solution with removing lt*.m4 files. I proposed
> > two solutions.
> >
> > a) @@ -325,6 +325,9 @@ structure
> >
> > %build autoreconf -ivf +#nice comment with explanation problem with
> > autoreconf on rhel5 +# bash-3.2# autoreconf -if +# You should
> > update your `aclocal.m4' by running aclocal. +# Putting files in
> > AC_CONFIG_AUX_DIR, `build'. +aclocal + %configure \ 
> > --disable-static
> >
> > b) small modification of your patch. @@ -324,6 +324,9 @@ structure
> >
> > %build + +#nice comment with explanation +rm -f m4/* 2>/dev/null 
> > autoreconf -ivf %configure \ --disable-static
>
> I prefer option b) here. Sorry, I misunderstood your previous email.

It is modification of your patch. Would you mind to prepare the new one?

LS