All,
Looking at getting kmplayer built and I'm running into function that are so
deprecated, they have been dropped from xine-lib/xine-ui - What to do here? Look
at finding a compatible newer version of kmplayer that isn't that old that can
replace the GIT source and build in todays world? How do these type issues get
fixed?
--
David C. Rankin, J.D.,P.E.
All,
What is usually involved in updating the packages to get rid of the
'-fpermissive' build flag requirement brought on by gcc47? What do you look for?
Just remove '-fpermissive' and build over and over fixing along the way or is
there a better way?
By my count, the following packages require '-fpermissive' with gcc47:
amarok
digikam
kaffeine
kipi-plugins
kmplayer (other issues as well)
koffice (still requires libpng15 fixes)
krusader
python-tqt
rosegarden
tdeadmin
tdebase
tdeedu
tdegames
tdegraphics
tdepim
Those are just those out of the packages I have built. There are probably
others as well. Any suggestions?
--
David C. Rankin, J.D.,P.E.
Has anyone been building tqca and tqca-tls as 64-bit packages?
They fail for not finding libtqt-mt.so. This is the snippet from the configure file:
============================================
if [ "$?" != "0" ]; then
rm -rf .qconftemp
echo fail
echo
echo "There was an error compiling 'conf'. Be sure you have a proper"
echo "TQt 3.x Multithreaded (MT) build environment set up."
if [ ! -f "$QTDIR/lib/libtqt-mt.so.3" ]; then
echo
echo "One possible reason is that you don't have"
echo "libtqt-mt.so.3 installed in $QTDIR/lib/."
fi
echo
exit 1;
fi
============================================
I have $LIBDIR exported as /opt/trinity/lib64, but the tqca/tqca-tls configuration seems to be hard-coded to $PREFIX/lib.
I'm probably missing something obvious because I see oodles of 64-bit RPM packages online, meaning the packages build on 64-bit.
Currently I have all Trinity related 64-bit lib files installing to /opt/trinity/lib64. I'm just beginning to build everything for 64-bit, but other than these two packages, I seem to be proceeding okay. I'm presuming the two need to be patched or I have something misconfigured in my build scripts.
Thanks.
Darrell
All,
I have built digikam on libpng15. There were two simple fixes for:
if (setjmp(png_jmpbuf(png_ptr)))
The remaining errors involved:
digikamthumbnail.cpp:416:17: error: invalid use of incomplete type 'png_info
{aka struct png_info_def}'
In file included from digikamthumbnail.cpp:96:0:
/usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct
png_info_def}'
digikamthumbnail.cpp:419:17: error: invalid use of incomplete type 'png_info
{aka struct png_info_def}'
In file included from digikamthumbnail.cpp:96:0:
/usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct
png_info_def}'
digikamthumbnail.cpp:425:17: error: invalid use of incomplete type 'png_info
{aka struct png_info_def}'
In file included from digikamthumbnail.cpp:96:0:
The above all involved references like:
if (info_ptr->color_type == PNG_COLOR_TYPE_RGB_ALPHA)
I know the 'info_ptr->color_type' is the problem. That's wrong due to no
longer having direct access to the png struct. Looking at other patches, it
looked like I could simply do:
if (color_type == PNG_COLOR_TYPE_RGB_ALPHA)
Since we have already made the call to:
png_get_IHDR(png_ptr, info_ptr, (png_uint_32 *) (&w32),
(png_uint_32 *) (&h32), &bit_depth, &color_type,
&interlace_type, NULL, NULL);
color_type should already hold the color type. So is just using 'color_type'
correct?
Digikam builds fine, but I need somebody to verify the patch. Darrell, we will
need to add preprocessor checks for the libpng version. I haven't done that yet.
The consolidated patch is attached for review.
--
David C. Rankin, J.D.,P.E.
I decided to build against Qt3 rather than TQt3. First time in a long time.
The patch we used recently to build avahi-tqt against TQt3 can't be used when building against Qt3. The patch is good only when building against TQt3. I presume the proper way to implement the patch is to add some preprocessor checks so packagers don't have to worry about the issue. For myself I added the following test in my avahi-tqt build script:
if [ -r ${PREFIX}/lib/pkgconfig/tqt-mt.pc ] || [ -r /usr/lib/pkgconfig/tqt-mt.pc ]; then
cat $CWD/avahi-tqt-fixes.diff | patch -p1 --verbose --no-backup-if-mismatch || exit 1
fi
tdebase fails to build:
/dev/shm/tdebase.build/kicker/kicker/core/kmenubase.ui.h:7: error: 't_xdisplay' was not declared in this scope
As neither tqt_xdisplay nor qt_xdisplay is used in the source file, why does the file compile against TQt3 and not Qt3?
Darrell
Calvin, Slavek, Liddell,
I'm trying to fix tdepim to build with gcc47, but I don't understand how to
make sure I'm fixing the right 'it' iterator. Specifically, the multiple
declaration issue is:
/build/src/tdepim/kmail/kmsystemtray.cpp: In member function 'void
KMSystemTray::updateNewMessages()':
/build/src/tdepim/kmail/kmsystemtray.cpp:485:48: error: redeclaration of
'TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it'
/build/src/tdepim/kmail/kmsystemtray.cpp:475:55: error:
'TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it' previously declared here
The code beginning at line 473 is:
void KMSystemTray::updateNewMessages()
{
for ( TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it =
mPendingUpdates.begin();
it != mPendingUpdates.end(); ++it)
{
KMFolder *fldr = it.key();
if ( !fldr ) // deleted folder
continue;
/** The number of unread messages in that folder */
int unread = fldr->countUnread();
TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it =
mFoldersWithUnread.find(fldr);
bool unmapped = (it == mFoldersWithUnread.end());
/** If the folder is not mapped yet, increment count by numUnread
in folder */
if(unmapped) mCount += unread;
/* Otherwise, get the difference between the numUnread in the folder and
* our last known version, and adjust mCount with that difference */
else
{
int diff = unread - it.data();
mCount += diff;
}
Looking through the comments and context, there seems to be two 'it'
iterators involved:
TQMap<.., bool>::...it
TQMap<.., int>::...it
with the 'bool' declaration being the loop index and the 'int' being used to
determine if the folder with unread messages is unmapped. The 'bool' dec seems
to be the one used to access the class data (i.e. it.key(), it.data()) If I'm
reading that correctly, then we can correct the 'int' iterator by renaming it
something like 'unread_it'
TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it =
mFoldersWithUnread.find(fldr);
bool unmapped = (unread_it == mFoldersWithUnread.end());
What say the experts. Is my reading of which 'it' can be renamed correct?
--
David C. Rankin, J.D.,P.E.
I have so much enjoyed being able to disable the cycling feature with the task bar and pager applet (bug reports 251 and 908). Both patches have reduced my irritability/anxiety levels. :)
'Tis the little things that often affect us most. :)
Darrell