Bug 1064696
Summary: | older automake1* don't really work with libtool 2.x | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Hin-Tak Leung <htl10> |
Component: | libtool | Assignee: | Pavel Raiskup <praiskup> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | htl10, phracek, praiskup, rhbugs |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-04-07 15:21:13 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Hin-Tak Leung
2014-02-13 06:12:10 UTC
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. |