On (07/04/14 18:57), Jakub Hrozek wrote:
>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@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@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@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?
Ignoring error with older automake:
The only drawback is libraries will not rebuilt on RHEL6 if version symbol
files are changed.
Next commands will not have any effect.
touch ini/libini_config.sym
make
Workaround is to use make clean && make (or touch any other source file)
We are doing review on fedora 19+. We will catch warnings from newer automake.
If we don not want to have warning on rhel6 we can maintain dependencies
manually because ding-libs doesn't have complicated dependencies.
libini_config_la_DEPENDENCIES = \
ini/libini_config.sym \
$(libini_config_la_LIBADD)
LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
