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

Lukas Slebodnik lslebodn at redhat.com
Fri Jul 11 12:47:01 UTC 2014


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 <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])
>>> 
>>> 
>>> 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



More information about the sssd-devel mailing list