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?
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?
Yes, you are correct. When dealing with these problems, I look at the way gcc treated the variable's scope before the change; i.e. within a given scope (usually a set of curly braces, though there are other ways to create a temporary scope) once the new "it" object was created, all accesses to "it" until the end of the current scope (excluding new scopes within the current scope) are going to be treated as accessing the new "it" object.
Confused yet? :-)
Tim
On 04/18/2012 04:49 PM, Timothy Pearson wrote:
What say the experts. Is my reading of which 'it' can be renamedcorrect?
Yes, you are correct. When dealing with these problems, I look at the way gcc treated the variable's scope before the change; i.e. within a given scope (usually a set of curly braces, though there are other ways to create a temporary scope) once the new "it" object was created, all accesses to "it" until the end of the current scope (excluding new scopes within the current scope) are going to be treated as accessing the new "it" object.
Confused yet? :-)
Tim
Yes,
But, please with progress. Before this fix, tdepim failed at 30%, not it builds all the way to 70%!
[ 70%] Building CXX object korganizer/korgac/CMakeFiles/korgac.dir/alarmdialog.cpp.o cd /build/src/build/korganizer/korgac && /usr/bin/c++ -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -fpermissive -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/src/build/korganizer/korgac -I/build/src/tdepim -I/build/src/tdepim/korganizer -I/build/src/tdepim/libtdepim -I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -o CMakeFiles/korgac.dir/alarmdialog.cpp.o -c /build/src/tdepim/korganizer/korgac/alarmdialog.cpp /build/src/tdepim/korganizer/korgac/alarmdialog.cpp: In member function 'void AlarmDialog::eventNotification()': /build/src/tdepim/korganizer/korgac/alarmdialog.cpp:501:32: error: redeclaration of 'TQValueListKCal::Alarm*::ConstIterator it' /build/src/tdepim/korganizer/korgac/alarmdialog.cpp:489:32: error: 'TQListViewItemIterator it' previously declared here
Damn, this is starting to look familiar! I'll apply that same logic to this one and keep going...
On 04/18/2012 05:01 PM, David C. Rankin wrote:
Damn, this is starting to look familiar! I'll apply that same logic to this one and keep going...
Need verification of this patch that fixes the tdepim gcc47 build issues. It fixes 2 iterator redeclarations, then fixes the missing '#inlcude <unistd.h>' issues in caldav and carddav. All in all fairly simple fixes.
Let me know what the experts think. Thanks.
Now all we need is help with digikam libpng15 issues and then I can fix the gcc47 build issues there. Implementing the libpng15 fixes will take a more seasoned coder than I. Fixing build issues is one thing, but implementing library changes - not even close..
Now all we need is help with digikam libpng15 issues and then I can fix the gcc47 build issues there. Implementing the libpng15 fixes will take a more seasoned coder than I. Fixing build issues is one thing, but implementing library changes - not even close..
Check the mail list archives. I posted a digikam patch about a week ago. Here:
http://humanreadable.nfshost.com/trinity/patches/digikam/digikam-libpng15.di...
No promises. As I mentioned previously, I only added preprocessor tests for the versions, as I did with the gwenview patch. Even if the updated patch fails, the preprocessor tests are needed anyway.
Darrell
On 04/18/2012 07:14 PM, Darrell Anderson wrote:
Now all we need is help with digikam libpng15 issues and then I can fix the gcc47 build issues there. Implementing the libpng15 fixes will take a more seasoned coder than I. Fixing build issues is one thing, but implementing library changes - not even close..
Check the mail list archives. I posted a digikam patch about a week ago. Here:
http://humanreadable.nfshost.com/trinity/patches/digikam/digikam-libpng15.di...
No promises. As I mentioned previously, I only added preprocessor tests for the versions, as I did with the gwenview patch. Even if the updated patch fails, the preprocessor tests are needed anyway.
Darrell
Thanks Darrell,
The preprocessor stuff works, but the digikam build still fails in the same spot. I've looked and it's Greek to me. We need an experienced coder to take a look at this one...
pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:129:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' In file included from ../../../../digikam/digikam/daboutdata.h:36:0, from pngloader.cpp:51: /usr/include/png.h:857:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::save(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:540:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' In file included from ../../../../digikam/digikam/daboutdata.h:36:0, from pngloader.cpp:51: /usr/include/png.h:857:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:677:39: warning: deprecated conversion from string constant to 'png_charp {aka char*}' [-Wwrite-strings] pngloader.cpp: In member function 'long int Digikam::PNGLoader::formatStringList(char*, size_t, const char*, __va_list_tag*)': pngloader.cpp:985:55: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:96:41: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result]
On 04/18/2012 07:14 PM, Darrell Anderson wrote:
Now all we need is help with digikam libpng15 issues and then I can fix the gcc47 build issues there. Implementing the libpng15 fixes will take a more seasoned coder than I. Fixing build issues is one thing, but implementing library changes - not even close..
Check the mail list archives. I posted a digikam patch about a week ago. Here:
http://humanreadable.nfshost.com/trinity/patches/digikam/digikam-libpng15.di...
No promises. As I mentioned previously, I only added preprocessor tests for the versions, as I did with the gwenview patch. Even if the updated patch fails, the preprocessor tests are needed anyway.
Darrell
Thanks Darrell,
The preprocessor stuff works, but the digikam build still fails in the same spot. I've looked and it's Greek to me. We need an experienced coder to take a look at this one...
pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:129:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' In file included from ../../../../digikam/digikam/daboutdata.h:36:0, from pngloader.cpp:51: /usr/include/png.h:857:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::save(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:540:9: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}' In file included from ../../../../digikam/digikam/daboutdata.h:36:0, from pngloader.cpp:51: /usr/include/png.h:857:16: error: forward declaration of 'png_struct {aka struct png_struct_def}' pngloader.cpp:677:39: warning: deprecated conversion from string constant to 'png_charp {aka char*}' [-Wwrite-strings] pngloader.cpp: In member function 'long int Digikam::PNGLoader::formatStringList(char*, size_t, const char*, __va_list_tag*)': pngloader.cpp:985:55: warning: function might be possible candidate for 'gnu_printf' format attribute [-Wmissing-format-attribute] pngloader.cpp: In member function 'virtual bool Digikam::PNGLoader::load(const TQString&, Digikam::DImgLoaderObserver*)': pngloader.cpp:96:41: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result]
-- David C. Rankin, J.D.,P.E.
The jmpbuf usage should be fixed in GIT hash 7d0d82b. Let me know if you run into any further digikam build problems...
Tim
On 04/18/2012 09:15 PM, Timothy Pearson wrote:
The jmpbuf usage should be fixed in GIT hash 7d0d82b. Let me know if you run into any further digikam build problems...
Tim
Thank you Tim,
I had stumbled across a fix I am currently trying for pngloader.cpp (123):
if (setjmp(png_jmpbuf(png_ptr)))
It looks like it made good progress past the original failure point, but then failed with:
albummanager.cpp: In member function 'void Digikam::AlbumManager::slotDatesJobData(KIO::Job*, const TQByteArray&)': albummanager.cpp:1582:26: error: redeclaration of 'Digikam::AlbumIterator it' albummanager.cpp:1557:43: error: 'TQMap<TQPair<int, int>, int>::iterator it' previously declared here
That one -- I think I can handle now :) I'll pull the commit down tonight and start again in the morning.
I had picked through the firefox libpng15 updated to find:
// we need to do the setjmp here otherwise bad things will happen - if (setjmp(decoder->mPNG->jmpbuf)) { + if (setjmp(png_jmpbuf(decoder->mPNG))) {
...but it was very slow going :) I'll let you know in the morning. Things look promising. The first setjmp error would fail with only 1 min. of build, now the redeclaration hits at 4 minutes, so progress has been made!
The jmpbuf usage should be fixed in GIT hash 7d0d82b. Let me know if you run into any further digikam build problems...
Does the 7d0d82b patch build digikam with gcc 4.7 or do we still need the other patch too?
Darrell
On 04/19/2012 12:40 PM, Darrell Anderson wrote:
Does the 7d0d82b patch build digikam with gcc 4.7 or do we still need the other patch too?
Darrell
No, other fixes are required to build with gcc47. (See digikam post for patch -- or bug 958)
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson