Hi,

I have a problem with this commit (Google cache of the commit forum) from 17 Feb 2009.

I get the following error (using kdesvn-build, SNV checkout of both, the kdesvn-build script and kdepimlibs a few minutes ago)

Code: Select all

[ 16%] Building CXX object akonadi/CMakeFiles/akonadi-kde.dir/itemfetchjob.o
/usr/local/kdesvn/kdepimlibs/akonadi/itemfetchjob.cpp: In member function ‘void Akonadi::ItemFetchJobPrivate::startFetchJob()’:
/usr/local/kdesvn/kdepimlibs/akonadi/itemfetchjob.cpp:90: error: expected `;' before ‘AKONADI_PARAM_EXTERNALPAYLOAD’
make[2]: *** [akonadi/CMakeFiles/akonadi-kde.dir/itemfetchjob.o] Error 1


Since the commit is nine days old, I guess it's something with my setup and not a temporary break of kdepimlibs. Gcc version is 4.2.4 on Gentoo.

Any ideas?

Unusual. I used kdesvn-build two days ago to build kdepimlibs without error. Do any other errors appear prior to this one?
G++/GCC version: 4.3.2

I don't see any errors before in the log files and tried over night a complete rebuild with a clean build directory without success, as Gianluca also tried in the other thread. It's really a bit strange as gcc complains about a simple syntax error. Switching to gcc 4.3.3 does also not help.

The problematic line is in it's context

Code: Select all

  //TODO: detect somehow if server supports external payload attribute
  command += " " AKONADI_PARAM_EXTERNALPAYLOAD;

So I just commented it out, since it looks like my server does non support the "external payload attribute", whatever that means.

After that kdepimlibs did compile and install fine. Hmmm ... is this a bug? The author seems to know that this code segment can cause problems. How can I make my sever to support "external payloads"?

[Edit] Just mailed the author of the patch, maybe he has a simple solution to this.

I also have this issue; these are the lasts 100 lines of the error.log:

Code: Select all

-- Configuring done
CMake Warning at /opt/kde4/share/apps/cmake/modules/KDE4Macros.cmake:868 (add_library):
  Cannot generate a safe linker search path for target akonadi-kde because
  files in some directories may conflict with libraries in implicit
  directories:

    link library [libakonadiprotocolinternals.so] in /usr/lib may be hidden by files in:
      /opt/kde4/lib

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  akonadi/CMakeLists.txt:132 (kde4_add_library)


CMake Warning at /opt/kde4/share/apps/cmake/modules/KDE4Macros.cmake:868 (add_library):
  Cannot generate a safe runtime search path for target akonadi-kde because
  files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libakonadiprotocolinternals.so.1] in /usr/lib may be hidden by files in:
      /opt/kde4/lib

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  akonadi/CMakeLists.txt:132 (kde4_add_library)


-- Generating done
-- Build files have been written to: /usr/src/kde4/build/kdepimlibs
[  0%] [  0%] Built target kresources-handbook
Built target imap-handbook
[  0%] Built target ldap-handbook
[  0%] Built target nntp-handbook
[  0%] Built target pop3-handbook
[  0%] Built target smtp-handbook
[  0%] Built target gpgmepp_automoc
[  0%] Built target gpgmepp-pth_automoc
[  0%] Built target qgpgme_automoc
[  0%] Built target gpgmepp-pthread_automoc
[  0%] Built target kmime_automoc
[  0%] Built target akonadi-kabc_automoc
[  0%] Built target akonadi-kmime_automoc
[  0%] Built target kresources_automoc
[  0%] Built target akonadi-kde_automoc
[  0%] Built target kldap_automoc
[  0%] Built target kabc_automoc
[  0%] [  0%] Built target kabc_file_core_automoc
Built target kabcformat_binary_automoc
[  0%] Built target kpimutils_automoc
[  0%] Built target kabc_file_automoc
[  0%] Built target kabc_directory_automoc
[  0%] Built target kabc_net_automoc
[  0%] Built target kabc_ldapkio_automoc
[  0%] Built target kcal_automoc
[  0%] Built target syndication_automoc
[  0%] Built target kblog_automoc
[  0%] Built target kxmlrpcclient_automoc
[  0%] Built target kcal_local_automoc
[  0%] Built target kcal_localdir_automoc
[  0%] Built target kholidays_automoc
[  0%] Built target kimap_automoc
[  0%] Built target kcm_kresources_automoc
[  0%] Built target kpimidentities_automoc
[  0%] Built target ktnef_automoc
[  0%] Built target mailtransport_automoc
[  0%] Built target kcm_mailtransport_automoc
[  0%] Built target kio_sieve_automoc
[  0%] Built target kio_ldap_automoc
[  0%] Built target kio_mbox_automoc
[  0%] Built target kio_imap4_automoc
[  0%] Built target kio_nntp_automoc
[  0%] Built target kio_pop3_automoc
[  0%] Built target kio_smtp_automoc
[  4%] [  8%] Built target gpgmepp-pth
Built target gpgmepp
Linking CXX shared library ../lib/libkmime.so
[ 13%] Built target gpgmepp-pthread
[ 16%] Built target kmime
Linking CXX shared library ../lib/libkresources.so
[ 17%] Building CXX object akonadi/CMakeFiles/akonadi-kde.dir/itemfetchjob.o
[ 20%] Built target kresources
[ 20%] Building CXX object akonadi/CMakeFiles/akonadi-kde.dir/itemmonitor.o
/usr/src/kde4/kdepimlibs/akonadi/itemfetchjob.cpp: In member function ‘void Akonadi::ItemFetchJobPrivate::startFetchJob()’:
/usr/src/kde4/kdepimlibs/akonadi/itemfetchjob.cpp:90: error: expected `;' before ‘AKONADI_PARAM_EXTERNALPAYLOAD’
make[2]: *** [akonadi/CMakeFiles/akonadi-kde.dir/itemfetchjob.o] Errore 1
make[2]: *** In attesa di lavori non terminati...
Linking CXX shared library ../lib/libkldap.so
make[1]: *** [akonadi/CMakeFiles/akonadi-kde.dir/all] Errore 2
make[1]: *** In attesa di lavori non terminati...
[ 24%] Built target kldap
make: *** [all] Errore 2


It should be related to the upgrade to kdesvnbuild 1.8, i suppose.

Well, it could be related to the kdesvn-build script, I also thought that, but I think we can now be more specific: It's a problem with the configuration of the akonadi server. Somehow our server seems not to be configured to handle the "external payload attribute", as the comment in the source code says. The author of that code segment comments that writing a detection for that is on his todo list.

Well, I was impudent enough to simply comment the offending line out (it's line number 90 in kdepimlibs/akonadi/itemfetchjob.cpp). kdepimlibs compiles and installs now fine, but I'm not sure if I have broke anything else with that. And of course you have to revert that change before your next kdesvn-build run, otherwise svn up will complain (but will also give you instructions how to revert that change automatically)

I also wrote an email to the author of that svn commit, asking him if he could give advice how to solve that problem in a more elegant way than to edit the code each time.

At least now I know the reason ... but currently don't have a fix for it.

Gianluca you also have another KDE 4.x installation beside Trunk from SVN, right?

The problem is that kdesvn-build looks into the wrong places for the header files. The macro AKONADI_PARAM_EXTERNALPAYLOAD is defined in protocol_p.h. Searching for that file I found two versions of it, one in /usr/local/kde/include/akonadi/private/protocol_p.h, which belongs to my KDE Trunk version and another one in /usr/include/akonadi/private/protocol_p.h, which belongs to my KDE 4.2 version.

The first one has the definition of AKONADI_PARAM_EXTERNALPAYLOAD, the latter doesn't have it as it was intruced by a SVN commit after the 4.2 release. kdesn-build wrongly includes the 4.2 version of that header file, which gives of course the mentioned error.

For a quick test I tried to rename the 4.2 header file directory to private.old. And indeed the problem changed. Now some header files aren't found at all. So I would say this is a bug in the kdesvn-build script, using wrong paths to look for the header files.

It's a bit annoying, since this is the second bug, which makes it at least difficult to install stable and trunk versions side by side (the other one is kdebase tries to write to system-wide directories, which is also unsolved).


[Edit] OK, got it working. As mentioned I renamed the "wrong" include directory. The I ran

Code: Select all

$ kdesvn-build --reconfigure  kdepimlibs

which finally compiled an installed kdepimlibs without any errors. After that I renamed the 4.2 include directory back. Now I'm a little scary if kdesvn-build did search for header files in the wrong places for other modules as well, so each time a changed header file compared to 4.2 will require the same trick ...

Gianluca, can you confirm that this also solves your proble, so I can change the subject to [SOLVED]? Maybe this also related to your missing mysql header files when compiling extragear/multimedia.

Threads can be marked as solved with the "It's Solved" button.

You may want to set the variable CMAKE_PREFIX_PATH to the directory where you install KDE.
( export CMAKE_PREFIX_PATH=/directory/where/compiled/kde/is/installed/ )

Yes, it worked also for me furanku's tip. But i don't have an other kde installation, i just installed the akonadi-server package from kubuntu-experimental repo because it's a dependence. It should be a kdesvn-build's bug and you could report it to bugs.kde.org . Thanks for your help!

This is not a bug in kdesvn-build. It is just that Akonadi is not being found properly on your system. As said above, you need to set CMAKE_PREFIX_PATH then reconfigure.

Well, kdesvn-build is supposed to download the sources, compile them and install the results without any further user interaction. It uses it's own set of config-vars for that purpose, like kdedir, qtdir and source-dir. One would expect, that you don't need to tell kdesvn-build (or the build tools it calls) to tell where itself installed kdesupport, when it's header files are needed to compile kdepimlibs, wouldn't you agree?

Agreed, although in this case it is actually CMake causing the problem. The author of kdesvn-build may wish to consider setting CMAKE_PREFIX_PATH before commencing configuration and build to avoid errors like this.

furanku wrote:[Edit] OK, got it working. As mentioned I renamed the "wrong" include directory. The I ran

Code: Select all

$ kdesvn-build --reconfigure  kdepimlibs

which finally compiled an installed kdepimlibs without any errors. After that I renamed the 4.2 include directory back. Now I'm a little scary if kdesvn-build did search for header files in the wrong places for other modules as well, so each time a changed header file compared to 4.2 will require the same trick ...

What exactly did you rename to what? I'm having the same problem.

Thanks

I'm not sure if this is the correct or most elegant method. I took a look into by bash history and I renamed /usr/include/akonadi/ to /usr/include/akonadi.old (sorry, wrote it wrong in the previous posting, but according to Gianuca renaming /usr/include/akonadi/private to /usr/include/akonadi/private.old did also works).

As I run gentoo, Gianluca Ubuntu and you Kubuntu it may be possible that your akonadi include directories from the distributions installation are stored in other places. Did you try bcooksley's advice to set CMAKE_PREFIX_PATH to your KDE Trunk base directory and then run kdesvn-build --reconfigure? Maybe all that renaming is unnecessary by that.

I tried the CMAKE_PREFIX_PATH but it didn't fix the problem. Renaming that folder did.
I guess this ain't the preferred way but it'll do. Thanks!

I feel a bit uneasy encouraging people to rename system installation directories ... so be sure remember all your changes to undo them in case they cause other troubles! Distro developers certainly will hate me for messing up their packages.