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

Stephen Gallagher sgallagh at redhat.com
Thu Jul 10 14:51:51 UTC 2014


-----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 <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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO+qIcACgkQeiVVYja6o6MgaQCfT1wDOhHf8Z0c0Y9GCXpccamI
Y2sAn2B2S04zHk9cvDRXHn82zI+dreyA
=ofZ8
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list