FTBFS - krusader - no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>'
Tim, Darrell, All,
krusader used to build consistently, but I've now run into an iterator issue that looks like it might be another gcc 4.7 issue. The error is:
g++ -DHAVE_CONFIG_H -I. -I../.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGEFILE64_SOURCE -DKDE_NO_COMPAT -DQT_NO_ASCII_CAST -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fpermissive -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT expander.o -MD -MP -MF .deps/expander.Tpo -c -o expander.o expander.cpp In file included from /opt/trinity/include/kfileitem.h:31:0, from ../Panel/listpanel.h:37, from expander.cpp:20: /opt/trinity/include/kfilemetainfo.h:1237:34: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:66:0, from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:62, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h: In instantiation of 'struct std::iterator_traits<TQValueListConstIterator<KURL> >': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: required by substitution of 'template<class _Iter> typename std::iterator_traits::iterator_category std::__iterator_category(const _Iter&) [with _Iter = TQValueListConstIterator<KURL>]' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: required from '_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = TQValueListConstIterator<KURL>; _Predicate = std::unary_negate<std::const_mem_fun_ref_t<bool, KURL> >]' expander.cpp:674:102: required from here /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:166:53: error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>' In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:63:0, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h: In instantiation of '_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = TQValueListConstIterator<KURL>; _Predicate = std::unary_negate<std::const_mem_fun_ref_t<bool, KURL> >]': expander.cpp:674:102: required from here /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: note: candidate is: In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:66:0, from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:62, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: note: template<class _Iter> typename std::iterator_traits::iterator_category std::__iterator_category(const _Iter&) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: note: substitution of deduced template arguments resulted in errors seen above
Is this a gcc 4.7.1 issue or a renaming issue?
Tim, Darrell, All,
krusader used to build consistently, but I've now run into an iterator issue that looks like it might be another gcc 4.7 issue. The error is:
<snip>
That is definitely a gcc 4.7.x "problem".
Tim
On 06/25/2012 11:04 PM, Timothy Pearson wrote:
<snip>
That is definitely a gcc 4.7.x "problem".
Tim
I don't think so, I built krusader last on 6/5/12 without a hitch:
Jun 5 16:39 tde-krusader-3.5.14_dev-9-x86_64.pkg.tar.xz
That was on gcc 4.7.0. Now if something between 4.7.0 and 4.7.1 caused this, I'll buy that, but looking at the 'Template' nature of the error itself, it looks to me like a TQt name change has a template wonky.
But, I defer totally to you on theses issues :) So, what do I look for to fix it? This isn't a simple it -> it2 error, this is a matching template not found thingy... and I can't even spell <Template> :)
On 06/25/2012 11:04 PM, Timothy Pearson wrote:
<snip>
That is definitely a gcc 4.7.x "problem".
Tim
I don't think so, I built krusader last on 6/5/12 without a hitch:
Jun 5 16:39 tde-krusader-3.5.14_dev-9-x86_64.pkg.tar.xz
That was on gcc 4.7.0. Now if something between 4.7.0 and 4.7.1 caused this, I'll buy that, but looking at the 'Template' nature of the error itself, it looks to me like a TQt name change has a template wonky.
That is what is strange--as far as I can tell nothing changed in TQt3 that would cause this problem. I am strongly suspecting a gcc issue, likely gcc became more strict with the 4.7.1 release and is choking on some bad code in krusader. What that code is I cannot say. ;-)
Tim
I don't think so, I built krusader last on 6/5/12 without a hitch:
That was on gcc 4.7.0. Now if something between 4.7.0 and 4.7.1 caused this, I'll buy that, but looking at the 'Template' nature of the error itself, it looks to me like a TQt name change has a template wonky.
That is what is strange--as far as I can tell nothing changed in TQt3 that would cause this problem. I am strongly suspecting a gcc issue, likely gcc became more strict with the 4.7.1 release and is choking on some bad code in krusader. What that code is I cannot say. ;-)
I built krusader in Slackware Current with gcc 4.7.1.
Darrell
On 06/26/2012 08:49 AM, Darrell Anderson wrote:
I built krusader in Slackware Current with gcc 4.7.1.
Darrell
Hmm... darn. I haven't changed anything with the build script. Does anyone know what this error is telling me? From what I see, I see 2 errors:
(1) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:166:53: error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>'
(2) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)'
Which I break down to (1) error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>' and (2) error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)' Unfortunately, that all breaks down to template gobbledy-gook to me :( I have no idea how to chase template errors.
Darrell, what does your build script look like? I'm building with:
./configure \ --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --localstatedir=/var \ --enable-debug=full
I'll keep poking around. The full error is below. If you see something that pops out, let me know...
g++ -DHAVE_CONFIG_H -I. -I../.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -D_LARGEFILE64_SOURCE -DKDE_NO_COMPAT -DQT_NO_ASCII_CAST -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT expander.o -MD -MP -MF .deps/expander.Tpo -c -o expander.o expander.cpp In file included from /opt/trinity/include/kfileitem.h:31:0, from ../Panel/listpanel.h:37, from expander.cpp:20: /opt/trinity/include/kfilemetainfo.h:1237:34: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:66:0, from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:62, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h: In instantiation of 'struct std::iterator_traits<TQValueListConstIterator<KURL> >': /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: required by substitution of 'template<class _Iter> typename std::iterator_traits::iterator_category std::__iterator_category(const _Iter&) [with _Iter = TQValueListConstIterator<KURL>]' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: required from '_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = TQValueListConstIterator<KURL>; _Predicate = std::unary_negate<std::const_mem_fun_ref_t<bool, KURL> >]' expander.cpp:674:102: required from here /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:166:53: error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>' In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:63:0, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h: In instantiation of '_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = TQValueListConstIterator<KURL>; _Predicate = std::unary_negate<std::const_mem_fun_ref_t<bool, KURL> >]': expander.cpp:674:102: required from here /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: note: candidate is: In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:66:0, from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/algorithm:62, from expander.cpp:13: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: note: template<class _Iter> typename std::iterator_traits::iterator_category std::__iterator_category(const _Iter&) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:202:5: note: substitution of deduced template arguments resulted in errors seen above
Darrell, what does your build script look like? I'm building with:
./configure \ --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --localstatedir=/var \ --enable-debug=full
CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --mandir=${MANDIR} \ --with-qt-dir=${QTDIR} \ --with-qt-includes=${QT_INCLUDE_DIR} \ --with-qt-libraries=${QT_LIB_DIR} \ --disable-rpath \ $DEBUG_AUTOTOOL_OPT || exit 1
I have some Trinity build peculiarities too, although krusader is not one of them. pytdeextensions, tdebindings, tdenetwork, amarok. They build in one Slackware release but not necessarily in another. Hopefully we get these anomalies figured out soon. :-)
Darrell
On 06/26/2012 10:32 AM, Darrell Anderson wrote:
I have some Trinity build peculiarities too, although krusader is not one of them. pytdeextensions, tdebindings, tdenetwork, amarok. They build in one Slackware release but not necessarily in another. Hopefully we get these anomalies figured out soon. :-)
I'll wager the amarok failure is due to musicbrainz tunepimp dependency no longer building against libmp4v2 that I posted about in the other thread. Amarok should build fine on earlier slack releases, but probably not the latest.
I have some Trinity build peculiarities too, although
krusader is not one of them. pytdeextensions, tdebindings, tdenetwork, amarok. They build in one Slackware release but not necessarily in another. Hopefully we get these anomalies figured out soon. :-)
I'll wager the amarok failure is due to musicbrainz tunepimp dependency no longer building against libmp4v2 that I posted about in the other thread. Amarok should build fine on earlier slack releases, but probably not the latest.
I don't build amarok with the musicbrainz dependency because musicbrainz is not part of the stock Slackware.
For me, amarok and tdenetwork refuse to build unless I reverse commit 477d071b (bug report 1040). I don't need to reverse that patch for any other package.
Darrell
On 06/26/2012 10:23 AM, David C. Rankin wrote:
On 06/26/2012 08:49 AM, Darrell Anderson wrote:
I built krusader in Slackware Current with gcc 4.7.1.
Darrell
Hmm... darn. I haven't changed anything with the build script. Does anyone know what this error is telling me? From what I see, I see 2 errors:
(1) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_iterator_base_types.h:166:53: error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>'
(2) /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algo.h:4490:41: error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)'
Which I break down to (1) error: no type named 'iterator_category' in 'class TQValueListConstIterator<KURL>' and (2) error: no matching function for call to '__iterator_category(TQValueListConstIterator<KURL>&)' Unfortunately, that all breaks down to template gobbledy-gook to me :( I have no idea how to chase template errors.
Is there any way this is a name collision problem like described in:
http://www.cplusplus.com/forum/general/11428/
I don't think so, I built krusader last on 6/5/12 without a hitch:
That was on gcc 4.7.0. Now if something between 4.7.0 and 4.7.1 caused this, I'll buy that, but looking at the 'Template' nature of the error
itself,
it looks to me like a TQt name change has a template wonky.
That is what is strange--as far as I can tell nothing changed in TQt3 that would cause this problem. I am strongly suspecting a gcc issue, likely gcc became more strict with the 4.7.1 release and is choking on some bad code in krusader. What that code is I cannot say. ;-)
I built krusader in Slackware Current with gcc 4.7.1.
Darrell
Interesting. Something must be weird/broken on David's system and I cannot even begin to guess what that something is!
Tim
I built krusader in Slackware Current with gcc 4.7.1.
Interesting. Something must be weird/broken on David's system and I cannot even begin to guess what that something is!
Likewise for me with tdenetwork, amarok, pytdeextensions, tdebindings.
There are days when I want to ditch the computers. :-)
The painful part is each package must be rebuilt to test single changes.
Darrell
On 06/26/2012 11:37 AM, Darrell Anderson wrote:
Likewise for me with tdenetwork, amarok, pytdeextensions, tdebindings.
There are days when I want to ditch the computers. :-)
The painful part is each package must be rebuilt to test single changes.
Darrell
I'm just going to start over with a fresh chroot and build everything again. I've google the template substitution errors and iterator_category http://www.sgi.com/tech/stl/iterator_category.html and there is nothing accept a name collision or SFINAE that comes up. Substitution failure is not an error (SFINAE) refers to a situation in C++ where an invalid substitution of template parameters is not in itself an error.
None of it makes ANY sense.
On 06/26/2012 11:37 AM, Darrell Anderson wrote:
I built krusader in Slackware Current with gcc 4.7.1.
Interesting. Something must be weird/broken on David's system and I cannot even begin to guess what that something is!
Likewise for me with tdenetwork, amarok, pytdeextensions, tdebindings.
The 'Weird' part is amarok builds just fine on my system. All I did was remove the tunepimp dependency. tdenetwork also builds fine. Maybe there are still some growing pains in gcc 4.7.1 and Slack/Arch/Fedora all have varying patches/fixes applied to get around it. Dunno, but builds here/not there should at least be explainable...
The 'Weird' part is amarok builds just fine on my system. All I did was remove the tunepimp dependency. tdenetwork also builds fine. Maybe there are still some growing pains in gcc 4.7.1 and Slack/Arch/Fedora all have varying patches/fixes applied to get around it. Dunno, but builds here/not there should at least be explainable...
I thought I was building amarok with no musicbrainz dependency, but now that I look at my configuration options I see nothing explicitly doing that. I got confused with my tdemultimedia build script, which has such an explicit option.
Which amarok build option do you use to disable musicbrainz/tunepimp?
Darrell
On 06/26/2012 12:42 PM, Darrell Anderson wrote:
The 'Weird' part is amarok builds just fine on my system. All I did was remove the tunepimp dependency. tdenetwork also builds fine. Maybe there are still some growing pains in gcc 4.7.1 and Slack/Arch/Fedora all have varying patches/fixes applied to get around it. Dunno, but builds here/not there should at least be explainable...
I thought I was building amarok with no musicbrainz dependency, but now that I look at my configuration options I see nothing explicitly doing that. I got confused with my tdemultimedia build script, which has such an explicit option.
Which amarok build option do you use to disable musicbrainz/tunepimp?
Darrell
Mine was a specific list dependency for Arch:
depends=('libmp4v2' 'libmysqlclient>=5.1.34' 'postgresql-libs>=8.3.7' 'ruby' 'tde-tdebase') # 'tunepimp>=0.5.3'
I just removed tunepimp as from the Arch dependency list. The rest of the build I have like this:
# fix konquisidebar include failure sed -i '/${TQT_INCLUDE_DIRS}/s|$|\n /opt/trinity/include|' \ amarok/amarok/src/konquisidebar/CMakeLists.txt
# fix "riokarma support is not buildable, it needs to link to karma-sharp.dll" sed -i '/tde_message_fatal(/s|^|#|' \ amarok/amarok/src/mediadevice/riokarma/CMakeLists.txt
mkdir -p build cd build
msg "Starting cmake..." CXXFLAGS="${CXXFLAGS} -I/usr/include/ruby-1.9.1 -fpermissive" \ cmake ${srcdir}/${pkgname#*-} \ -DCMAKE_INSTALL_PREFIX=${TDEDIR} \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DWITH_LIBVISUAL=ON \ -DWITH_KONQSIDEBAR=ON \ -DWITH_XINE=ON \ -DWITH_YAUAP=OFF \ -DWITH_IPOD=ON \ -DWITH_IFP=ON \ -DWITH_NJB=ON \ -DWITH_MTP=OFF \ -DWITH_RIOKARMA=OFF \ -DWITH_DAAP=OFF \ -DBUILD_ALL=ON
Mine was a specific list dependency for Arch:
depends=('libmp4v2' 'libmysqlclient>=5.1.34' 'postgresql-libs>=8.3.7' 'ruby' 'tde-tdebase') # 'tunepimp>=0.5.3'
I just removed tunepimp as from the Arch dependency list. The rest of the build I have like this:
Okay, I see. You did not explicitly configure amarok to build without tunepimp/musicbrainz, you instead removed those packages, which caused amarok to build without that support.
In the automake days there was a build option to build with/without musicbrainz, but that build option never got migrated to cmake. Hence the bug report.
# fix konquisidebar include failure sed -i '/${TQT_INCLUDE_DIRS}/s|$|\n /opt/trinity/include|' \ amarok/amarok/src/konquisidebar/CMakeLists.txt
Which failure is this? I have -DWITH_KONQSIDEBAR=ON in my build script but have not noticed any failures.
# fix "riokarma support is not buildable, it needs to link to karma-sharp.dll" sed -i '/tde_message_fatal(/s|^|#|' \
amarok/amarok/src/mediadevice/riokarma/CMakeLists.txt
Why not just use -DWITH_RIOKARMA=OFF?
Darrell
On 06/26/2012 09:03 PM, Darrell Anderson wrote:
# fix konquisidebar include failure
sed -i '/${TQT_INCLUDE_DIRS}/s|$|\n /opt/trinity/include|' \ amarok/amarok/src/konquisidebar/CMakeLists.txt
Which failure is this? I have -DWITH_KONQSIDEBAR=ON in my build script but have not noticed any failures.
IIRC both of these are already fixed.
# fix "riokarma support is not buildable, it needs to link to karma-sharp.dll" sed -i '/tde_message_fatal(/s|^|#|' \
amarok/amarok/src/mediadevice/riokarma/CMakeLists.txt
Why not just use -DWITH_RIOKARMA=OFF?
I do :)
-DWITH_MTP=OFF \ -DWITH_RIOKARMA=OFF \ -DWITH_DAAP=OFF \ -DBUILD_ALL=ON
This was necessary when building with riokarma ON, but I nixed it do to the mono requirement -- didn't want the overhead.
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson