|
Description
Darrell
2012-06-17 13:09:27 CDT
We will need to figure out why tdenetwork and amarok are failing. As far as I can tell 477d071b is needed to prevent embarrassing errors during initial CMake configuration. Here is the build failure output from amarok: Scanning dependencies of target amarokcore-static make[2]: Leaving directory `/dev/shm/amarok.build' make -f amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/build.make amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/build make[2]: Entering directory `/dev/shm/amarok.build' /usr/bin/cmake -E cmake_progress_report /dev/shm/amarok.build/CMakeFiles [ 1%] Building CXX object amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcopiface_skel.cpp.o cd /dev/shm/amarok.build/amarok/src/amarokcore && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -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/opt/trinity/include -I/usr/include/tqt -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/dev/shm/amarok.build/amarok/src/amarokcore -I/dev/shm/amarok/amarok/src/amarokcore -I/dev/shm/amarok.build -I/dev/shm/amarok/amarok/src -I/dev/shm/amarok/amarok/src/statusbar -I/opt/trinity/include -I/usr/include/tqt -I/usr/include/taglib -fPIC -o CMakeFiles/amarokcore-static.dir/amarokdcopiface_skel.cpp.o -c /dev/shm/amarok.build/amarok/src/amarokcore/amarokdcopiface_skel.cpp /usr/bin/cmake -E cmake_progress_report /dev/shm/amarok.build/CMakeFiles [ 1%] Building CXX object amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o cd /dev/shm/amarok.build/amarok/src/amarokcore && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -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/opt/trinity/include -I/usr/include/tqt -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/dev/shm/amarok.build/amarok/src/amarokcore -I/dev/shm/amarok/amarok/src/amarokcore -I/dev/shm/amarok.build -I/dev/shm/amarok/amarok/src -I/dev/shm/amarok/amarok/src/statusbar -I/opt/trinity/include -I/usr/include/tqt -I/usr/include/taglib -fPIC -o CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o -c /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual bool Amarok::DcopScriptHandler::runScript(const TQString&)': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:914: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual bool Amarok::DcopScriptHandler::stopScript(const TQString&)': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:919: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp: In member function 'virtual TQStringList Amarok::DcopScriptHandler::listRunningScripts()': /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:924: error: 'ScriptManager' has not been declared make[2]: *** [amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/amarokdcophandler.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/amarok.build' make[1]: *** [amarok/src/amarokcore/CMakeFiles/amarokcore-static.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/amarok.build' make: *** [all] Error 2 Here is the build failure output from tdenetwork: [ 40%] Building CXX object kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o cd /dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -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/opt/trinity/include -I/usr/include/tqt -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/dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src -I/dev/shm/tdenetwork/kopete/libkopete -I/opt/trinity/include -I/usr/include/tqt -fPIC -o CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o -c /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:43: /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: ISO C++ forbids declaration of 'SASL' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: expected ';' before '*' token In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:48: /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.h:38: warning: 'typedef' was ignored in this declaration /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp: In constructor 'ClientStream::Private::Private()': /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:78: error: 'tls' was not declared in this scope make[2]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/tdenetwork.build' make[1]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/tdenetwork.build' make: *** [all] Error 2 tdenetwork builds fine here: http://quickbuild.pearsoncomputing.net:58080/3108073/buildlog_ubuntu-precise-i386.tdenetwork-trinity_4%3A14.0.0-0ubuntu7%2Br158%2Bpr17~precise_FULLYBUILT.txt.gz Not sue what is different on your system, but I would start by looking to see if any includes needed by gwclientstream.cpp are in a non-standard location. tdenwtwork, gwclientstream.cpp includes: tqapplication.h -> /usr/include/tqt/tqapplication.h tqguardedptr.h -> /usr/include/tqt/tqguardedptr.h tqobject.h -> /usr/include/tqt/tqobject.h tqptrqueue.h -> /usr/include/tqt/tqptrqueue.h tqtimer.h -> /usr/include/tqt/tqtimer.h bytestream.h -> /usr/include/unicode/bytestream.h connector.h -> /usr/include/linux/connector.h request.h -> /usr/include/dns/request.h NOT INSTALLED ON SYSTEM: coreprotocol.h securestream.h tlshandler.h I don't know what packages those header files are from or why, with those header files missing, tdenetwork did not fail to build before commit 477d071b. Oh, never mind. Sheesh. Those three header files are part of tdenetwork/kopete. Seems then the header files are all acounted for. Do you have more than one instance of qca.h present on your system? /opt/trinity/include/qca.h, installled by tqca. Should I temporarily uninstall tqca and try without reverting the 477d071b patch? (In reply to comment #8) > /opt/trinity/include/qca.h, installled by tqca. > > Should I temporarily uninstall tqca and try without reverting the 477d071b > patch? That would be worth a shot. It looks like the wrong header is being pulled in, probably because of a subtle change to the CXXFLAGS. The amarok failure: 'ScriptManager' has not been declared The tdenetwork failure: error: 'tls' was not declared in this scope Should the remedy be to declare those variables? Removing the tqca and tqca-tls packages before building tdenetwork made no difference. I saw a different set of "not declared in this scope" messages, but the same type of failure. (In reply to comment #10) > The amarok failure: > > 'ScriptManager' has not been declared > > The tdenetwork failure: > > error: 'tls' was not declared in this scope > > Should the remedy be to declare those variables? No. Those are classes and for some reason the header files that define them are not being included. One way for that to happen would be that g++ is using system headers instead of the headers in the module source, or vice versa. How do I troubleshoot? As I seem to be the only one reporting the problem, the first presumption should be PEBKAC. I presume something in my build scripts or build process. tdenetwork configuration:
cd ${TMP}/${PRGNAM}.build
cmake $SOURCES_ROOT \
-DCMAKE_C_FLAGS:STRING="$CPUOPT" \
-DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_SKIP_RPATH=OFF \
-DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \
-DLIB_SUFFIX=${LIBDIRSUFFIX} \
-DMAN_INSTALL_DIR=${MANDIR} \
-DWITH_ARTS=ON \
-DWITH_SPEEX=ON \
-DWITH_WEBCAM=ON \
-DBUILD_WIFI=ON \
-DWITH_JINGLE=ON \
-DBUILD_KOPETE_PROTOCOL_TESTBED=ON \
-DBUILD_KOPETE_PROTOCOL_GROUPWISE=ON \
-DBUILD_KOPETE_PROTOCOL_MSN=ON \
-DBUILD_KOPETE_PROTOCOL_IRC=ON \
-DBUILD_KOPETE_PROTOCOL_YAHOO=ON \
-DBUILD_KOPETE_PROTOCOL_WINPOPUP=ON \
-DBUILD_KOPETE_PROTOCOL_JABBER=ON \
-DBUILD_ALL=ON || exit 1
amarok configuration:
cd ${TMP}/${PRGNAM}.build
cmake $SOURCES_ROOT \
-DCMAKE_C_FLAGS:STRING="$CPUOPT" \
-DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_SKIP_RPATH=OFF \
-DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \
-DLIB_SUFFIX=${LIBDIRSUFFIX} \
-DMAN_INSTALL_DIR=${MANDIR} \
-DWITH_XINE=ON \
-DWITH_LIBVISUAL=ON \
-DWITH_KONQSIDEBAR=ON \
-DWITH_IPOD=ON \
-DWITH_YAUAP=ON \
-DWITH_NJB=ON \
-DWITH_MTP=ON \
-DWITH_DAAP=ON \
-DWITH_IFP=ON \
-DWITH_MP4V2=OFF \
-DWITH_RIOKARMA=OFF \
-DBUILD_ALL=ON || exit 1
Bumping to Critical as there exists a work-around although the root cause remains unresolved. Reversing commit 477d071b does cure the issue here. fedora17, x86_64, cmake -DCMAKE_INSTALL_PREFIX=/opt/trinity \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DWITH_WEBCAM=ON \ -DWITH_ARTS=ON \ -DBUILD_ALL=ON \ -DWITH_JINGLE=ON \ -DWITH_SPEEX=ON \ -DWITH_WEBCAM=ON \ -DWITH_GSM=OFF \ -DBUILD_KOPETE_PROTOCOL_ALL=ON \ -DBUILD_KOPETE_PLUGIN_ALL=ON \ .. Thanks. Now we know the problem is not distro-specific. :-) The only thing that patch did was add TQT_CFLAGS to the list of compiler flags. Can you post your TQT_CFLAGS variable from inside CMakeFiles? Thanks! ================================================================ Here are the TQT_CFLAGS variables with commit 477d071b reversed: tdenetwork: TQT_CFLAGS:INTERNAL=-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/opt/trinity/include;-I/usr/include/tqt TQT_CFLAGS_I:INTERNAL= TQT_CFLAGS_OTHER:INTERNAL=-DQT_NO_ASCII_CAST;-DQT_CLEAN_NAMESPACE;-DQT_NO_STL;-DQT_NO_COMPAT;-DQT_NO_TRANSLATION;-DQT_THREAD_SUPPORT;-D_REENTRANT;-include;tqt.h amarok: DBUS_TQT_CFLAGS:INTERNAL=-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include DBUS_TQT_CFLAGS_I:INTERNAL= DBUS_TQT_CFLAGS_OTHER:INTERNAL= ... TQT_CFLAGS:INTERNAL=-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/opt/trinity/include;-I/usr/include/tqt TQT_CFLAGS_I:INTERNAL= TQT_CFLAGS_OTHER:INTERNAL=-DQT_NO_ASCII_CAST;-DQT_CLEAN_NAMESPACE;-DQT_NO_STL;-DQT_NO_COMPAT;-DQT_NO_TRANSLATION;-DQT_THREAD_SUPPORT;-D_REENTRANT;-include;tqt.h ================================================================ Here are the TQT_CFLAGS variables without reversing commit 477d071b, which causes the builds to fail: tdenetwork: TQT_CFLAGS:INTERNAL=-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/opt/trinity/include;-I/usr/include/tqt TQT_CFLAGS_I:INTERNAL= TQT_CFLAGS_OTHER:INTERNAL=-DQT_NO_ASCII_CAST;-DQT_CLEAN_NAMESPACE;-DQT_NO_STL;-DQT_NO_COMPAT;-DQT_NO_TRANSLATION;-DQT_THREAD_SUPPORT;-D_REENTRANT;-include;tqt.h amarok: DBUS_TQT_CFLAGS:INTERNAL=-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include DBUS_TQT_CFLAGS_I:INTERNAL= DBUS_TQT_CFLAGS_OTHER:INTERNAL= ... TQT_CFLAGS:INTERNAL=-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/opt/trinity/include;-I/usr/include/tqt TQT_CFLAGS_I:INTERNAL= TQT_CFLAGS_OTHER:INTERNAL=-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 don't see a difference between the two. I decided to look into this again after a long while. I see now why you don't see the failure and we do: you're building with autotools and we're building with cmake. :) After resurrecting some old build scripts and tinkering, I am able to build amarok with autotools with no failures. So that somewhat implies the problem is with cmake. I haven't yet tried to fine tune the cmake build options to narrow the possibilities. Thus far I am unable to build tdenetwork with autotools. The build keeps failing because I don't have libgadu installed. I don't see a configure option to ignore that and the configure process does not seem to look for that anymore. I've never had libgadu installed and was able to build with autotools with autotools before the cmake conversion. I haven't tinkered further with tdenetwork cmake options. tdenetwork:
This turned out to be nightmare, but I now can build with cmake without failure and without reversing commit 477d071b.
There were two components that always failed to build under cmake: kopete protocol jabber and groupwise.
The fix required four patches.
The first patch is from bug report 1274.
I'm attaching the remaining three cmake patches here and they need to be applied in the order provided.
The first two patches address build failures regarding QCA. The qca.h header (from the tqca package) refers to TQCA and not QCA, which tdenetwork still refers.
The third patch is housekeeping to improve readability.
My final cmake build options:
-DCMAKE_C_FLAGS:STRING="$CPUOPT" \
-DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_SKIP_RPATH=ON \
-DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \
-DLIB_SUFFIX=${LIBDIRSUFFIX} \
-DMAN_INSTALL_DIR=${MANDIR} \
-DWITH_ARTS=ON \
-DWITH_WEBCAM=ON \
-DWITH_JINGLE=ON \
-DWITH_SPEEX=ON \
-DBUILD_WIFI=ON \
-DBUILD_KOPETE_PROTOCOL_ALL=ON \
-DBUILD_KOPETE_PROTOCOL_GADU=OFF \
-DBUILD_KOPETE_PROTOCOL_MEANWHILE=OFF \
-DBUILD_KOPETE_PLUGIN_ALL=ON \
-DBUILD_ALL=ON || exit 1
NOTICE: I don't use kopete and don't now how. After building with the patches, somebody needs to perform usability tests.
Hopefully this resolves the cmake related issues. More on automake in a subsequent comment.
Created attachment 911 [details]
Patch to build with cmake (1)
First patch.
Created attachment 912 [details]
Patch to build with cmake (2)
Second patch.
Created attachment 913 [details]
Houscleaning patch (3)
Third patch.
Regarding the libgadu failures when building with automake, the cause is commits 4721accb 2011-06-22 and 1e22120b 2011-06-21, which removed support for an internal libgadu, and the initial cmake conversion, commit ac876806 2011-05-22, which removed the internal libgadu sources. With no internal libgadu and the respective commits, tdenetwork always defaults to compiling with an external libgadu. That in itself is a good idea but when that external package is not installed then the automake build fails. Reversing both 2011-06 commits will not help because the internal libgadu does not exist, unless the internal libgadu is restored as well. We probably don't want to maintain or restore those sources. With automake, tdenetwork needs a simple test to default to not building gadu support at all when the external libgadu is not found. The problem is $COMPILE_GADU is always true. Setting COMPILE_GADU="" allows the build to proceed. A proposed libgadu patch is attached. With the patch the package builds with automake. With automake there is a configure message that OpenSLP support will not be built. There are no such messages with cmake. Although the OpenSLP package is not installed, thereby causing those messages with automake, the real problem is OpenSLP support was not added to the cmake conversion. I filed bug report 1278 to address that issue. The following configure warning message appears with automake: Warning: No moc-able header file for /dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/ignore_this_warning This message is supposed to be for building with unsermake, which is not used with Trinity. I'm attaching a proposed patch to eliminate that message. With automake there is a configure warning: "linux/if_ppp.h: present but cannot be compiled" when no such problem occurs with cmake. Following the tutorial at http://lists.gnu.org/archive/html/bug-autoconf/2003-05/msg00196.html, I'm attaching a proposed patch that builds tdenetwork with automake and no if_ppp.h configure errors. At this point there remains build failures when trying to build with jingle support with automake. I have a partial patch, but I will continue that discussion in bug report 1097. The package now builds with automake or cmake. An anomaly I notice with the automake build is CMakeLists.txt files in the doc/tde/HTML directory are part of the package. Another is the file sizes of the /opt/trinity/bin files all are much smaller than those in the cmake build. Created attachment 914 [details]
Patch to build with automake and libgadu not installed
Created attachment 915 [details]
Patch to build with automake and remove nuisance unsermake warning
Created attachment 916 [details]
Patch to build with automake and remove if_ppp errors
Created attachment 920 [details]
Patch to fix amarok build failure
amarok:
The problem with amarok not building is a name clash with scriptmanager.h. A file of the same name is installed to $TDEDIR/include from the tdelibs package. Apparently the build process is using the system scriptmanager.h rather than the local package version. The include order seems awry.
A simple solution, consistent with other such occurrences in the sources, is to modify amarokdcophandler.cpp:
AS IS:
#include "scriptmanager.h"
CHANGE TO:
#include "../scriptmanager.h"
I'm attaching a proposed patch.
I don't know why commit 477d071b causes this name clash or why reversing the commit avoids the name clash. I don't know why the problem does not occur with automake. I suspect we'll have more of these types of bugs in the future as packages are converted to cmake. I hope we find an explanation for the cause of the clash.
Slavek, During your next build run, would you please test these patches? If they work for you then we can presume the patches are sane and don't interfere with those folks who have not experienced these bugs. Please notice for tdenetwork there are both cmake and automake patches. Thanks. :) Created attachment 931 [details] Patch to build with automake and libgadu not installed (2) Darrell, I tried autotools patches (914, 915 and 916) and I have a problem with a patch from attachment 914 [details] - libdagu. Nowhere in tdenetwork did I find that was tested of the presence libgadu ==> LIBGG_LIBS is always empty, unless set 'manually' using --with-libgadu-libs. That's why I prepare another patch that adds verification of the presence libgadu. I'm just not sure how it was intended to be used use_libgadu_copy in your patch? Can a new patch to replace your previous patch or we will modify patch for use use_libgadu_copy? I'm running a build run tonight and I'll test the newer libgadu patch. Created attachment 932 [details] Updated automake/libadu patch I tested the patch in attachment 931 [details]. One change required: COMPILE_GADU= Seems when the variable COMPILE_GADU contains any value then the configuration presumes the external libgadu is installed and the build fails. Therefore the COMPILE_GADU variable must be emptied when libgadu is not installed. I'm attaching an updated patch. :) Interesting - I tried it on Ubuntu Quantal and worked for me with COMPILE_GADU=no. Make sure the new patch works on your system. :) (Odpověď na komentář #35) > Make sure the new patch works on your system. :) Confirmed - patch from attachment 932 [details] works well. Are the other patches in this bug report working for you too? If yes then I'm thinking we should start pushing these patches and other bug reports (like 1262) to GIT. We're getting to the point that keeping track of them all is getting confusing. :) (Odpověď na komentář #37) > Are the other patches in this bug report working for you too? > > If yes then I'm thinking we should start pushing these patches and other bug > reports (like 1262) to GIT. We're getting to the point that keeping track of > them all is getting confusing. :) Currently I have from this bug only tested patches for autotools - tdenetwork. Similarly, from the bug 1262. Now I'm trying to finish patches for tdenetwork before I test next patches. Comment on attachment 932 [details]
Updated automake/libadu patch
Pushed to GIT in hash 4a8e66dd
Comment on attachment 915 [details]
Patch to build with automake and remove nuisance unsermake warning
Pushed to GIT in hash 5df439b2
Comment on attachment 916 [details]
Patch to build with automake and remove if_ppp errors
Pushed to GIT in hash 60a2cf42
Comment on attachment 920 [details]
Patch to fix amarok build failure
Pushed to GIT in hash 9241945d.
I'm a little confused by the fact that already in the code are three identical "qcaprovider.h" and the patch from attachment 912 [details] adds a fourth?
kopete/protocols/groupwise/libgroupwise/qca/src/qcaprovider.h
kopete/protocols/jabber/libiris/iris/xmpp-core/qcaprovider.h
kopete/protocols/jabber/libiris/qca/src/qcaprovider.h
Yes: kopete/protocols/groupwise/libgroupwise/qca/src/qcaprovider.h kopete/protocols/jabber/libiris/iris/xmpp-core/qcaprovider.h kopete/protocols/jabber/libiris/qca/src/qcaprovider.h 4th -> tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/qcaprovider.h I reviewed the comments and at this moment I don't remember how I derived that second patch. So I ran a build test with that section of the patch removed and the package failed to build: /dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.h:37: error: expected constructor, destructor, or type conversion before '*' token So looks like we need 4 copies of qcaprovider.h in different locations --- unless somebody derives a better method. I tested the patches and I have two observations: 1) patch1 change in existing qcaprovider.h QCA* => TQCA*, but qcaprovider.h added in patch2 still contain QCA* 2) adding qcaprovider.h into kopete/protocols/jabber/libiris/iris/jabber causes for me FTBFS. I must add also qca.h into the same folder. Another observation - when I build using automake with all patches (including renaming QCA => TQCA in the newly added qcaprovider.h and also with added qca.h), it causes for me FTBFS: libiris/iris/xmpp-core/.libs/libiris_xmpp_core.a(libiris_xmpp_core_la-securestream.o): In function `SecureLayer': /root/tdenetwork-trinity-14.0.0/./kopete/protocols/jabber/libiris/iris/xmpp-core/securestream.c pp:143: undefined reference to `vtable for SecureLayer' /root/tdenetwork-trinity-14.0.0/./kopete/protocols/jabber/libiris/iris/xmpp-core/securestream.c pp:154: undefined reference to `vtable for SecureLayer' /root/tdenetwork-trinity-14.0.0/./kopete/protocols/jabber/libiris/iris/xmpp-core/securestream.c pp:131: undefined reference to `vtable for SecureLayer' /root/tdenetwork-trinity-14.0.0/./kopete/protocols/jabber/libiris/iris/xmpp-core/securestream.c pp:131: undefined reference to `vtable for SecureLayer' collect2: error: ld returned 1 exit status Okay, let's back up a step. :) I filed this report because I could not build tdenetwork unless I reversed commit 477d071b. I'm not a code guru and the patches I submitted here worked for me. That does not mean the patches are sane or sound, only that they worked for me. The original build failure I saw is in Comment 3. Ideally we want tdenetwork to build for both of us (Debian and Slackware) without patching. Currently I can't build without reversing commit 477d071b and you can. If you see something obvious in Comment 3 then by all means please propose a new patch. All I want is to build without reversing commit 477d071b and to build correctly. :) In the mean time, I'll try building again without these patches. Possibly through one of the other tdenetwork bug reports the problem was resolved. Without the attached patches I receive the following build failure: /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: expected ',' or '...' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: expected ')' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: ISO C++ forbids declaration of 'SASL' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: 'QCA' has not been declared /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: ISO C++ forbids declaration of 'TLS' with no type /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: expected ';' before '*' token /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:78: error: 'tls' was not declared in this scope Created attachment 1013 [details]
Change QCA to TQCA
I tried to prepare a patch that could possibly reduce the number of duplicate "qcaprovider.h", changes QCA => TQCA (this should address mentioned FTBFS with cmake) and also solves FTBFS with automake.
For me R14 now builds successfully with both automake and cmake.
When using only the patch from attachment 1013 [details], I receive the following build failure:
/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.cpp:583: error: 'createProviderHash' was not declared in this scope
I should add that the build failure is with cmake. Interestingly, tdenetwork builds without incident with automake. As far as I can tell from the build log, jabber support built, although I explicitly disabled building jingle because jingle still fails to build. Created attachment 1016 [details]
Change QCA to TQCA, fix includes
I tried for include files that are not from the same folder change "..." to <...>. Please, try updated patch.
I tested the latest patch with cmake. Same build failure. No failure with automake with the latest patch: [ 63%] Building CXX object kopete/protocols/jabber/libiris/iris/jabber/CMakeFiles/iris_jabber-static.dir/s5b.cpp.o cd /dev/shm/tdenetwork.build/kopete/protocols/jabber/libiris/iris/jabber && /usr/bin/c++ -DHAVE_CONFIG_H -DHAVE_LINUX_VIDEODEV_H -O2 -march=i486 -mtune=i686 -ggdb -fvisibility=hidden -fvisibility-inlines-hidden -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/opt/trinity/include -I/usr/include/tqt -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/dev/shm/tdenetwork.build/kopete/protocols/jabber/libiris/iris/jabber -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../include -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../xmpp-im -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../xmpp-core -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../../cutestuff/util -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../../cutestuff/network -I/dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/../../qca/src -I/dev/shm/tdenetwork.build -I/opt/trinity/include -I/usr/include/tqt -fPIC -o CMakeFiles/iris_jabber-static.dir/s5b.cpp.o -c /dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.cpp /dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.cpp: In constructor 'XMPP::S5BManager::S5BManager(XMPP::Client*)': /dev/shm/tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/s5b.cpp:583: error: 'createProviderHash' was not declared in this scope make[2]: *** [kopete/protocols/jabber/libiris/iris/jabber/CMakeFiles/iris_jabber-static.dir/s5b.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/tdenetwork.build' make[1]: *** [kopete/protocols/jabber/libiris/iris/jabber/CMakeFiles/iris_jabber-static.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/tdenetwork.build' make: *** [all] Error 2 Created attachment 1017 [details] Change QCA to TQCA, fix including hash.h It seems clear that there is no difference "..." × <...> and I go back to the previous patch. The problem I see here: http://trinity-devel.pearsoncomputing.net/?0::10666 - createProviderHash is defined in tdenetwork/kopete/protocols/jabber/libiris/iris/xmpp-core/hash.h, but the during build for you is used the wrong hash.h (may be from /opt/trinity/include). I modified the patch to hash.h was included using a relative path to the correct file. Please try it out. Yes, of course. Good thinking! The same solution we used for amarok in this same bug report. The clash is caused by the existing hash.h installed by tqt3. With the latest patch I built tdenetwork with cmake. Why do these header clashes affect me and not others? Created attachment 1018 [details] Updated housecleaning patch Updated the housecleaning patch based on latest patch in attachment 1017 [details]. I tagged my original patches as obsolete. I uploaded an updated housekeeping patch. The patch only renders certain include statements more readable. Problem: Line 806 of the new housekeeping patch. Add a space in front of the first quotation mark: 805: -#include"s5b.moc" 806: +#include"s5b.moc" Change to 805: -#include"s5b.moc" 806: +#include "s5b.moc" The cmake configuration then will fail. Why? Does anybody know whether libjingle now works? Bug report 1097 addresses that issue. (Odpověď na komentář #57) > Change to > > 805: -#include"s5b.moc" > 806: +#include "s5b.moc" > > The cmake configuration then will fail. Why? I applied your patch from attachment 1018 [details] and both automake and also cmake build is for me without problems. Attachment 1017 [details] pushed to GIT in hash 68b5e386.
> I applied your patch from attachment 1018 [details] and both automake
> and also cmake build is for me without problems.
Yes, because my patch does not include the change I mentioned. Manually add a space before the quotation mark and try again with cmake.
The problem only occurs with cmake:
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for strings.h
-- Looking for strings.h - found
CMake Error: Attempt to add a custom rule to output "/dev/shm/tdenetwork.build/kopete/protocols/jabber/libiris/iris/jabber/s5b.moc.rule" which already has a custom rule.
-- checking for one of the modules 'gthread-2.0'
-- checking for one of the modules 'gmodule-2.0'
The problem is in tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/CMakeLists.txt. That file was created with the original sloppy header include. Adding a space in the include to improve readability is confusing the configuration in the CMakeLists.txt file.
The duplication problem seems to be a conflict between tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/Makefile.am and CMakeLists.txt. Why does adding a space cause this error? Created attachment 1029 [details] Fix cmake build: automoc × specific rule in kopete jabber protocol (Odpověď na komentář #62) > The duplication problem seems to be a conflict between > tdenetwork/kopete/protocols/jabber/libiris/iris/jabber/Makefile.am and > CMakeLists.txt. > > Why does adding a space cause this error? I found it - it's a similar problem, as I recently dealt with automake => AUTOMOC × specific rule for s5b.moc. Please test attached patch. Created attachment 1031 [details] Updated housecleaning patch Updated patch based upon using patch in attachment 1029 [details]. I updated the housecleaning patch (adding a space) in order to test the patch in attachment 1029 [details]. The problem only affects cmake and I had no problems building with cmake using all three patches.
Although our focus is to migrate to cmake, no problems with automake either.
Let's push the patches and close this report as resolved. :)
Attachment 1029 [details] pushed to GIT in hash b3fd6646.
Housekeeping patch in attachment 1031 [details] pushed to GIT in commit ff26edf4.
This resolves the bug report.
Thanks everybody for helping! :)
|