13 Jul
2012
13 Jul
'12
10:56 p.m.
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.
--
David C. Rankin, J.D.,P.E.
14 Jul
14 Jul
1:37 a.m.
New subject: [trinity-devel] automake 1.12 - removes support for 'AM_C_PROTOTYPES'
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
2:28 a.m.
New subject: [trinity-devel] automake 1.12 - removes support for 'AM_C_PROTOTYPES'
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.
2:33 a.m.
New subject: [trinity-devel] automake 1.12 - removes support for 'AM_C_PROTOTYPES'
On 07/13/2012 01:37 PM, Darrell Anderson 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?
Tim
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.
4:20 a.m.
New subject: [trinity-devel] automake 1.12 - removes support for 'AM_C_PROTOTYPES'
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
6:09 a.m.
New subject: [trinity-devel] automake 1.12 - removes support for 'AM_C_PROTOTYPES'
On Fri, 13 Jul 2012 14:20:14 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
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.
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?)
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".
4588
days inactive
4588
days old
5 comments
4 participants
participants (4)
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Timothy Pearson