Tim, All,
Just a general heads up. automake 1.12 removes support for AM_C_PROTOTYPES. We will need to grep the GIT tree to see if this impacts TDE. If the code still relies on AM_C_PROTOTYPES, then any automake build will fail with:
configure.in:22: error: automatic de-ANSI-fication support has been removed /usr/share/aclocal-1.12/protos.m4:12: AM_C_PROTOTYPES is expanded from... configure.in:22: the top level autom4te: /usr/bin/m4 failed with exit status: 1
The solution is simple, just delete the AM_C_PROTOTYPES reference. I haven't had time to check yet, but I thought I would pass it along.
Just a general heads up. automake 1.12 removes support for AM_C_PROTOTYPES. We will need to grep the GIT tree to see if this impacts TDE. If the code still relies on AM_C_PROTOTYPES, then any automake build will fail with:
configure.in:22: error: automatic de-ANSI-fication support has been removed /usr/share/aclocal-1.12/protos.m4:12: AM_C_PROTOTYPES is expanded from... configure.in:22: the top level autom4te: /usr/bin/m4 failed with exit status: 1
The solution is simple, just delete the AM_C_PROTOTYPES reference. I haven't had time to check yet, but I thought I would pass it along.
Looks like we would have to fix three spots in qt3 (that are replicated in tqt3):
grep -rn AM_C_PROTOTYPES .
./dependencies/tqt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
./dependencies/qt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
Darrell
On 07/13/2012 01:37 PM, Darrell Anderson wrote:
Looks like we would have to fix three spots in qt3 (that are replicated in tqt3):
grep -rn AM_C_PROTOTYPES .
./dependencies/tqt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
./dependencies/qt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
Darrell
Yep,
That would do it! Let Tim or someone else signoff, but I think you just delete them. They are not doing anything anymore :)
On 07/13/2012 01:37 PM, Darrell Anderson wrote:
Looks like we would have to fix three spots in qt3 (that are replicated in tqt3):
grep -rn AM_C_PROTOTYPES .
./dependencies/tqt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/tqt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
./dependencies/qt3/src/3rdparty/libmng/makefiles/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/configure.in:16:AM_C_PROTOTYPES ./dependencies/qt3/src/3rdparty/libmng/aclocal.m4:208:AC_DEFUN([AM_C_PROTOTYPES],
Darrell
Yep,
That would do it! Let Tim or someone else signoff, but I think you just delete them. They are not doing anything anymore :)
-- David C. Rankin, J.D.,P.E.
I notice that this problem is within Qt's builtin libmng instance. Does anyone even use the obsolete builtin libraries from Qt3, or can I just blow this directory away and force linking against the system's libmng instance?
Tim
I notice that this problem is within Qt's builtin libmng instance. Does anyone even use the obsolete builtin libraries from Qt3, or can I just blow this directory away and force linking against the system's libmng instance?
Sounds like a reasonable idea, so I'll play the role of PITA --- I mean devil's advocate. :-)
I have the following in my (T)Qt3 build scripts:
-qt-imgfmt-mng
That build option exists as a carryover from the days when Slackware still supported KDE3/Qt3.
* What happens right now with automake 1.11 if I delete that build option? Will (T)Qt3 find the installed libmng headers and libraries? Or will (T)Qt3 build without any mng support?
* When I use that build option, is my (T_Qt3 package using built-in mng support and ignoring the installed libmng package?
* If you delete the built-in mng support from (T)Qt3, I presume I need to update my build script and delete the -qt-imgfmt-mng build option?
* If you remove the built-in mng support, what happens when a distro does not support libmng? (Unlikely, but what if?)
* What harm is there to retain the built-in mng support and just update the make/configure files to be automake 1.12 compatible?
Darrell
On Fri, 13 Jul 2012 14:20:14 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I notice that this problem is within Qt's builtin libmng instance. Does anyone even use the obsolete builtin libraries from Qt3, or can I just blow this directory away and force linking against the system's libmng instance?
Sounds like a reasonable idea, so I'll play the role of PITA --- I mean devil's advocate. :-)
I have the following in my (T)Qt3 build scripts:
-qt-imgfmt-mng
That build option exists as a carryover from the days when Slackware still supported KDE3/Qt3.
What happens right now with automake 1.11 if I delete that build option? Will (T)Qt3 find the installed libmng headers and libraries? Or will (T)Qt3 build without any mng support?
When I use that build option, is my (T_Qt3 package using built-in mng support and ignoring the installed libmng package?
If you delete the built-in mng support from (T)Qt3, I presume I need to update my build script and delete the -qt-imgfmt-mng build option?
Gentoo has always used system libmng, AFAIK (it's listed as a dependency). It looks like using system libmng requires you to still pass -qt-imgfmt-mng to configure and add an additional flag, -system-libmng . Presumably the first flag controls whether or not mng is supported, and the second controls which libmng is used.
- If you remove the built-in mng support, what happens when a distro does not support libmng? (Unlikely, but what if?)
Presumably, compiling with neither flag set will remove any need for the library by disabling mng support. It isn't exactly the most heavily-used feature, so I wouldn't expect any complaints.
- What harm is there to retain the built-in mng support and just update the make/configure files to be automake 1.12 compatible?
Well, the two obvious arguments are "it's extra work" and "there may be useful bugfixes/features in recent libmng versions that people not able to navigate the bestiary of flags won't get".
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Timothy Pearson