Bug 249082

Summary: digiKam crashes on startup leaving message of unknown symbol
Product: [Applications] digikam Reporter: Jay Ambee <jmbarkei>
Component: Portability-RuntimeAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED DOWNSTREAM    
Severity: crash CC: jmbarkei, kde
Priority: NOR    
Version: 1.4.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 1.5.0
Sentry Crash Report:

Description Jay Ambee 2010-08-26 09:08:19 UTC
Version:           1.4.0 (using KDE 4.5.0) 
OS:                Linux

I am using OpenSuse 11.3 with KDE 4.5.0.

Since I installed both and digikam 1.3.0 I get the same program behaviour. I hoped, that with the forcoming new version it would vanish so I could use digikam again, but 1.4.0 shows exactly the same behaviour (which I think is an awesome programm altogether).

This is what happens:
On first startup I walk through the first time wizard and change nearly all options to the second on the list. Digikam starts up until "reading database" appears and the crashes.

When sarting digikam from the konsole I get this result:

###:~> digikam
QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work.
Time elapsed: 213 ms
Model: Time elapsed: 544 ms
TextureColorizer: Time elapsed: 131 ms
Time elapsed: 4 ms
Model: Time elapsed: 37 ms
digikam: symbol lookup error: /usr/lib/libdigikamcore.so.1: undefined symbol: _ZN11KDcrawIface19RawDecodingSettingsaSERKS0_
###p:~> 

Looks somehow like there is something missing... Or am I wrong? 

Thanks for your help

Jay

Reproducible: Always

Steps to Reproduce:
Happens every time the software starts.
I even deleted the digikam.rc file in ./kde4/share/config and the db-files in the /foto directory ("bilder" on my laptop, I'm german) and changed different entries in the first time wizard afterwards.

Actual Results:  
Software still crashes on startup.
Comment 1 Nicolas L. 2010-08-26 09:21:52 UTC
this is because you have a packaging issue it seems digikam and libdigikam are not from the same version.

Can you do :   

rpm -qa | grep digikam

and then make sure all packages are from 1.4.0
Comment 2 Jay Ambee 2010-08-26 10:50:25 UTC
No problem. I did:

###:~> rpm -qa | grep digikam
digikam-lang-1.4.0-46.1.noarch
digikam-1.4.0-46.1.i586
###:~>

I also looked for libdigikamcore.so.1, which is from 25.08.10, 20.32h which must be the packaging time yesterday from the package I installed this morning.
I "normalized" all digikam packages during the install of the last version, so I am quite sure their versions should match ... but you never know: anywhere else I could look??

Thanks a lot!

Jay
Comment 3 Jay Ambee 2010-08-26 10:51:07 UTC
No problem. I did:

###:~> rpm -qa | grep digikam
digikam-lang-1.4.0-46.1.noarch
digikam-1.4.0-46.1.i586
###:~>

I also looked for libdigikamcore.so.1, which is from 25.08.10, 20.32h which must be the packaging time yesterday from the package I installed this morning.
I "normalized" all digikam packages during the install of the last version, so I am quite sure their versions should match ... but you never know: anywhere else I could look??

Thanks a lot!

Jay
Comment 4 Jay Ambee 2010-08-26 10:52:40 UTC
Oh, that's nice ... one attempt and solved?? 

It's not as simple as that ... 

NOT RESOLVED!!!!

Thanks
Comment 5 Johannes Wienke 2010-08-26 11:32:11 UTC
This is definitely an issue of how your distribution packages digikam. Hence not a problem of digikam developers. Marking an issue as downstream tells this.
Comment 6 Jay Ambee 2010-08-26 12:18:36 UTC
Okay ... I see. And problem is solved now.

Looks like it really is a problem of openSUSE packaging:

digikam and kipiplugins are in 2 packages, then there is a third -doc-package which is described as the "build environment" and therefor seems to be unnecessary for the "normal" user.
But if you select it for installation, it does remind you of some more libs that are crucial for digikam and need to be updated. If you do so (even after deselecting the -doc-package again, everything is fine.

Bottom line:
Even if this is a problem of packaging: why do you accept as developers that crucial parts of your software are scattered around and dislocated so that the avarage user is in danger of getting a non-functional program next time he updates. Wouldn't it be easier and less enerving to create one complete package with all links and dependencies?

Sorry, just a question.

Thanks for your time!
Comment 7 Johannes Wienke 2010-08-26 12:50:47 UTC
This is essentially a decision to be made by the packagers of the distributions. Different distributions use different schemes of packaging.

In your case it looks like the packagers forgot to mark digikam as depending on these libraries (libkdcraw in your case).

Packaging digikam in the same package with the libraries is in any cast not acceptable as the libraries are required by other applications, too.