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

Lukas Slebodnik lslebodn at redhat.com
Thu Jul 10 09:46:57 UTC 2014


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 <sgallagh at redhat.com>
>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



More information about the sssd-devel mailing list