After KDE4 fires up, the akonadi server tries to start but gives a "not registered in dbus" error. I get this both with Slackware (vitualbox under Slamd64 12.2) and booting into Slackware64 (clean boot, no vm) and logged in as root. Any pointers?

I would like to check out the PIM functionality. I like a good PIM to organize contacts, appointments and such data, despite the rants I just read on alt.os.linux.slackware, such an app has is uses.

i get the same thing.... it's down pretty far on my to-do list..... still trying to figure out why my system hangs when terminating a session so i can log in under another user. and i'm also trying to figure out why i have a flashing screen and herringbone distortion when viewing DVD video...

that may have fixed it..... in the middle of a download right now, so i'll try a reboot later..... but when i logged in as root, and made the changes in that thread, and did a restart from the akonadi config manager, no more error window

Trying to find why it doesn't work with KDE 4.x.x. I have tried to run it manually:

bash-4.0$ akonadictl
akonadictl: error while loading shared libraries: libboost_program_options-mt.so: cannot open shared object file: No such file or directory
bash-4.0$

The library "libboost_program_options-mt.so" is not present.

I have make a simbolic link from "/usr/lib/libboost_program_options.so" to "/usr/lib/libboost_program_options-mt.so" and now it works.

It works for me, hope it does for you.

This is now 2010.March.26. And this problem still exists. However once I did this:
1.) ln -s /usr/lib/libboost_program_options.so /usr/lib/libboost_program_options-mt.so
2.) ln -s /usr/lib64/libboost_program_options.so /usr/lib64/libboost_program_options-mt.so
the problem ceased to exist. Konversation actually began working immediately by using the first example. But then as I was posting here, I realized that I needed that link for the Slackware64 installation. But nonetheless, Konversation is running now as I needed it to. So I'm guessing Akonadi is now working as well.

So why can't this already be done when you're installing the programs that depend on this link?

Xavian-Anderson Macpherson
Shingoshi

The problem only exists because you upgraded your boost package without upgrading all the packages which depend on boost.

Slackware 13.0 does not have this issue because there, boost still installs all those *-mt libraries. Slackware-current does not have your issue either, because all programs that depend on boost (which does not ship separate multithreading *-mt libraries any longer) have been recompiled to use the new boost libraries.

Eric

http://www.linuxquestions.org/questi...ml#post3805717

and the post above.

see
http://www.boost.org/doc/libs/1_42_0...library-naming

the -mt version is required for some builds

I still find it a bad idea to not split between multi threaded and single threaded version, eg what for holding data in thread local storage when my app uses no threads, just to slow it down?

as long as I can fix this myself I don't care about this

but I find it a absolute bad practice to free developers from thinking about what they are doing or using.
slackware never did such things
(boost was not part of slackware until 13 I think, it came with KDE4, and in a way where I find that it is wrong, and a bad idear of the kde project to not include the view boost parts they use into the kde build but create a new dependency)