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".