[SSSD] [PATCH][ding_libs] Add version symbol files

Jakub Hrozek jhrozek at redhat.com
Mon Apr 7 16:57:53 UTC 2014


On Mon, Mar 10, 2014 at 10:28:51PM +0100, Lukas Slebodnik wrote:
> On (10/03/14 14:31), Dmitri Pal wrote:
> >On 03/10/2014 02:30 AM, Lukas Slebodnik wrote:
> >>On (08/03/14 02:00), Dmitri Pal wrote:
> >>>On 03/08/2014 01:40 AM, Dmitri Pal wrote:
> >>>>On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
> >>>>>On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
> >>>>>>On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
> >>>>>>>On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
> >>>>>>>>On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
> >>>>>>>>>>>>>>attached patch addresses ticket #2193
> >>>>>>>>>Jan,
> >>>>>>>>>Do you have any other comments to the patch from previous mail?
> >>>>>>>>No further comments at this time. Please, just get it
> >>>>>>>>included already :}
> >>>>>>>>_______________________________________________
> >>>>>>>>sssd-devel mailing list
> >>>>>>>>sssd-devel at lists.fedorahosted.org
> >>>>>>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >>>>>>>I am preparing a new patch for ini and it will add two new entry
> >>>>>>>points but I can't finish the work until your patch is pushed.
> >>>>>>ACK from me. make, make check, make distcheck and make rpms work fine.
> >>>>>>
> >>>>>>SSSD also seems to be working fine after I upgraded ding-libs
> >>>>>>to the new
> >>>>>>RPMs.
> >>>>>Pushed to ding-libs master.
> >>>>>_______________________________________________
> >>>>>sssd-devel mailing list
> >>>>>sssd-devel at lists.fedorahosted.org
> >>>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> >>>>
> >>>>This push broke my deb builds on RHEL6:
> >>>s/deb/dev
> >>>
> >>>Also removing EXTRA_ prefix seems to fix the issue.
> >>>>[dpal at dpal ding-libs (master)]$ autoreconf -if
> >>>>libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'.
> >>>>libtoolize: copying file `build/ltmain.sh'
> >>>>libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
> >>>>libtoolize: copying file `m4/libtool.m4'
> >>>>libtoolize: copying file `m4/ltoptions.m4'
> >>>>libtoolize: copying file `m4/ltsugar.m4'
> >>>>libtoolize: copying file `m4/ltversion.m4'
> >>>>libtoolize: copying file `m4/lt~obsolete.m4'
> >>>>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 canonical
> >>>>name (possible typo)
> >>>>autoreconf: automake failed with exit status: 1
> >>>>
> >>>>
> >>The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want
> >>to augment the automake-generated _DEPENDENCIES variable rather than
> >>replacing it.
> >>http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html
> >>
> >>It is a syntax warning in automake<  1.11.3 and syntax warnings
> >>are enabled by default.
> >>http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
> >>
> >>Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is
> >>     defined but no program or library has `EXTRA_libini_config_la'
> >>     as canonical name  (possible typo)
> >>autoreconf: automake failed with exit status: 1
> >>
> >>It would be better don't treat warnings as errors in automake.
> >>
> >>The only negative of this solution is that library libini_conf will not be
> >>recompiled with older version of automake if files listed in
> >>EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override
> >>automatically generated dependencies calculated by automake with
> >>syntax: *_DEPENDENCIES
> >>
> >>Patch is attached.
> >>
> >>LS
> If _DEPENDENCIES is not supplied, it is computed by Automake.
> The automatically-assigned value is the contents of _LDADD or _LIBADD,
> with most configure substitutions, -l, -L, -dlopen and -dlpreopen options
> removed.
> 
> _DEPENDENCIES will overrride aotomatically generated dependencies because
> automake knows that author did it intentionaly and author has a good reason for
> this.
> 
> The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely want
> to augment the automake-generated _DEPENDENCIES variable rather than replacing
> it.
> 
> >But you use EXTRA prefix only with libini_config and not with other
> >libraries generated by this package. What is the difference?
> libpath_utils, libdhash, libcollection, libref_array, libbasicobjects are
> simple libraries and do not depend on other library. It is possible to use
> *_DEPENDENCIES because nothing will be overridden. EXTRA_*_DEPENDENCIES could
> be used as well.
> 
> libini_config depends on the other libraries.
> 
> libini_config_la_LIBADD = \
>     libcollection.la \
>     libpath_utils.la \
>     libref_array.la \
>     libbasicobjects.la
> 
> 1st version:
> libini_config_la_DEPENDENCIES = ini/libini_config.sym
> 
> The previous line will replace automake-generated dependencies. If
> libcollection is changed libini_config will not be rebuilt.
> Yes, you can still use: make clean && make to workaround this problem.
> It can cause weird behaviour if you forget to clean project.
> 
> 2nd version:
> EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
> 
> It works as expected with newer automake.
> 
> With automake < 1.11.3, EXTRA_*_DEPENDENCIES is ignored (unknown syntax)
> Automake-generated dependencies are not replaced. There is drawback
> libini_config will not be rebuilt if file ini/libini_config.sym is changed.
> Again, you can still use: make clean && make to workaround this problem.
> libini_config.sym will be usually changed together with other source codes.
> So, it is not very likely you will hit this situation.
> 
> 
> >I would have understood if all libraries used EXTRA prefix but it is
> >not the case. Or it is a bug?
> >
> >Package that I have is 1.11.1. There is no other version available.
> >
> >What is the recommendation with this issue?
> >
> 
> I was thinking about this issue and I can see yet another solution (workaround)
> which should work with older verions of automake.
> 
> 3rd version:
> We can add all dependencies manually because ding-libs doesn't have complicated
> dependencies
> 
> libini_config_la_DEPENDENCIES = \
>     ini/libini_config.sym \
>     libcollection.la \
>     libpath_utils.la \
>     libref_array.la \
>     libbasicobjects.la
> 
> or shorter version:
> libini_config_la_DEPENDENCIES = \
>     ini/libini_config.sym \
>     $(libini_config_la_LIBADD)
> 
> 
> I can see two options:
>     2nd version and do not treat automake warnings as errors
>     3rd version (workaround)
> 
> LS
> 
> BTW: automake warnings EXTRA_*_DEPENDENCIES are also in sssd.
> But each sssd developer use at least fedora 17.
> We can ignore this warning on el6 build.

I'm sorry, I forgot about this patch and didn't come back until I was
checking stale threads in patchwork today..

I would prefer to ignore automake warnings. Given the wide range of host
OS we support ranging from RHEL-6 to latest Fedora we're going to
continue running into incompatibilities and warninigs. I would prefer to
treat them as non-fatal if possible.

Do you see some downside to this? Do you anticipate that ignoring some
warnigns might cause a wrong build?



More information about the sssd-devel mailing list