Description of problem: http://bugs.ghostscript.com/show_bug.cgi?id=692040#c3 I came to file this because of the breakage in the above, and I was confident that part of ghostscript hasn't changed for 10+ years, and indeed I am able to do so on Darwin 8 with automake-1.6.3 and libtool 1.5 (1.1220 2003/04/05 19:32:58). It appears that the older automake1* fedora or redhat is providing simply does not work correctly with libtool 2.x (or current). Version-Release number of selected component (if applicable): automake1* libtool-2.4.2-23.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. empty new directory, echo AM_PROG_LIBTOOL > configure.ac 2. run aclocal-1.6 (or aclocal-1.7, etc) 3. Actual results: aclocal: macro `_LT_DECL_SED' required but not defined aclocal: macro `_LT_FUNC_STRIPNAME_CNF' required but not defined no aclocal.m4 generated. Expected results: with libtool 1.5 (1.1220 2003/04/05 19:32:58), it is silent & a new aclocal.m4 is generated. Additional info: The simplied steps don't actually work with automake-1.13 (fedora 20 current) with a far more extended and different messages, but the simplied steps is derived from part of ghostscript's, and the full version does work with current automake but fails with those two "required but not defined" messages against older automake-1.6/1.7. http://bugs.ghostscript.com/show_bug.cgi?id=692040#c3 In any case, if autmake1* is supposed to provide backward compatibility, it should work like it did against libtool 1.5 .
Hi Hin-Tak Leung, thanks for this report but TBH, I don't really know where the problem is. (In reply to Hin-Tak Leung from comment #0) > Description of problem: > > http://bugs.ghostscript.com/show_bug.cgi?id=692040#c3 > > I came to file this because of the breakage in the above, and I was > confident that part of ghostscript hasn't changed for 10+ years, and indeed > I am able to do so on Darwin 8 with automake-1.6.3 and libtool 1.5 (1.1220 > 2003/04/05 19:32:58). > > It appears that the older automake1* fedora or redhat is providing simply > does not work correctly with libtool 2.x (or current). This is not expected to work. Autotools features mutually inter-depend on concrete versions, etc.. When you are able to install (non existing package in F20) automake16, could you please install also older libtool? Where is the problem? I would suggest you to fix the configure.ac according to today's autotools (it should not be that hard). I can try to help you if you want. > Version-Release number of selected component (if applicable): > automake1* > libtool-2.4.2-23.fc20.x86_64 > > How reproducible: > always > > Steps to Reproduce: > 1. empty new directory, echo AM_PROG_LIBTOOL > configure.ac > 2. run aclocal-1.6 (or aclocal-1.7, etc) > 3. Why do you think this is supposed to work? If you use autoconf, you always should start with AC_INIT, etc. (Note that AM_PROG_LIBTOOL is obsoleted anyway). > In any case, if autmake1* is supposed to provide backward compatibility, it > should work like it did against libtool 1.5 . Sorry but this is not truth. Automake1* packages are old and not in Fedora anymore; please don't expect it will work. Hin-Tak Leung, I can try to help you to fix the real autotools problems but I need to see the real failure against current autotools, forget about the non-existing packages. Pavel
(In reply to Pavel Raiskup from comment #1) > This is not expected to work. Autotools features mutually inter-depend on > concrete versions, etc.. When you are able to install (non existing package > in F20) automake16, could you please install also older libtool? Where is > the > problem? I would suggest you to fix the configure.ac according to today's > autotools (it should not be that hard). I can try to help you if you want. ... > Sorry but this is not truth. Automake1* packages are old and not in Fedora > anymore; please don't expect it will work. ... It looks like as recent as f19 (I think still with f20, according to koji), a few older supposedly compat packages are provided. http://koji.fedoraproject.org/koji/packageinfo?packageID=1145 http://koji.fedoraproject.org/koji/packageinfo?packageID=1144 ------------------ $ rpm -qi automake14 automake17 Name : automake14 Version : 1.4p6 Release : 24.fc19 Architecture: noarch Install Date: Wed 03 Jul 2013 14:08:26 BST Group : Development/Tools Size : 700565 License : GPLv2+ Signature : RSA/SHA256, Thu 14 Mar 2013 15:50:41 GMT, Key ID 07477e65fb4b18e6 Source RPM : automake14-1.4p6-24.fc19.src.rpm Build Date : Thu 14 Feb 2013 00:11:38 GMT Build Host : buildvm-16.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://sources.redhat.com/automake Summary : A GNU tool for automatically creating Makefiles Description : Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This package contains Automake 1.4, an older version of Automake. You should install it if you need to run automake in a project that has not yet been updated to work with newer versions of Automake. Name : automake17 Version : 1.7.9 Release : 18.fc19 Architecture: noarch Install Date: Wed 03 Jul 2013 14:06:52 BST Group : Development/Tools Size : 745581 License : GPLv2+ and MIT and OFSFDL Signature : RSA/SHA256, Thu 14 Mar 2013 12:20:10 GMT, Key ID 07477e65fb4b18e6 Source RPM : automake17-1.7.9-18.fc19.src.rpm Build Date : Thu 14 Feb 2013 00:02:43 GMT Build Host : buildvm-14.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://sources.redhat.com/automake Summary : A GNU tool for automatically creating Makefiles Description : Automake is a tool for automatically generating `Makefile.in' files compliant with the GNU Coding Standards. This package contains Automake 1.7, an older version of Automake. You should install it if you need to run automake in a project that has not yet been updated to work with latest version of Automake. -------------------- The problem is that these older aclocal-* although have their own /usr/share/aclocal-* directory, still load stuff off /usr/share/aclocal (the latest). I understand this is probably a design decision since other software put m4 macros there so older aclocal-* still need access to that... Anyway, I am just thinking that the older aclocal-* and automake-* should either work or not be provided, although stupidly enough, there are a lot of autogen.sh or bootstrap.sh etc out there do exact matches, and the manual install of automake also install a versioned automake-* as well as an unversioned automake .
(In reply to Hin-Tak Leung from comment #2) > (In reply to Pavel Raiskup from comment #1) > > This is not expected to work. Autotools features mutually inter-depend on > > concrete versions, etc.. When you are able to install (non existing package > > in F20) automake16, could you please install also older libtool? Where is > > the > > problem? I would suggest you to fix the configure.ac according to today's > > autotools (it should not be that hard). I can try to help you if you want. > ... > > > Sorry but this is not truth. Automake1* packages are old and not in Fedora > > anymore; please don't expect it will work. > ... > > It looks like as recent as f19 (I think still with f20, according to koji), > a few older supposedly compat packages are provided. > > http://koji.fedoraproject.org/koji/packageinfo?packageID=1145 > http://koji.fedoraproject.org/koji/packageinfo?packageID=1144 Thanks for correction! Yes, these packages are still in F19, but we stopped shipping them from F20, mentioned builds were never shipped IIRC, not installable. Please let the automake1{4,7} die silently. > The problem is that these older aclocal-* although have their own > /usr/share/aclocal-* directory, still load stuff off /usr/share/aclocal (the > latest). I understand this is probably a design decision since other > software put m4 macros there so older aclocal-* still need access to that... > > Anyway, I am just thinking that the older aclocal-* and automake-* should > either work or not be provided, although stupidly enough, there are a lot of > autogen.sh or bootstrap.sh etc out there do exact matches, and the manual > install of automake also install a versioned automake-* as well as an > unversioned automake . Hin-Tak, I still don't know how could I help you. I don't plan touching automake14 and automake17 as these are dead and you should really at least plan convert your project to up2date automake. Fixing obsoleted automake would not make sense.. TBH, I am disoriented from what you expect, the problem was still not precisely specified, please go on if it is worth. If you propose something useful for 'automake', please fail bug against 'automake' component. Thanks, closing for now.