Bug 244697

Summary: [PATCH] pykde4-4.4.92 doesn't compile: can't use default assignment operator
Product: [Developer tools] bindings Reporter: Oldřich Jedlička <oldium.pro>
Component: generalAssignee: kde-bindings
Status: RESOLVED FIXED    
Severity: major CC: kevin.kofler, rdieter, scarpino, simon
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Build log from Gentoo build
Build fix
define a placeholder = operator

Description Oldřich Jedlička 2010-07-15 06:28:15 UTC
Created attachment 49161 [details]
Build log from Gentoo build

Version:           unspecified (using Devel) 
OS:                Linux

I have gcc 4.3.4, kdepimlibs-4.4.92, kdelibs-4.4.92. When compiling pykde4-4.4.92, I get an error:

...
/usr/include/akonadi/kmime/addressattribute.h: In member function ‘Akonadi::AddressAttribute& Akonadi::AddressAttribute::operator=(const Akonadi::AddressAttribute&)’:
/usr/include/akonadi/kmime/addressattribute.h:43: error: non-static const member ‘Akonadi::AddressAttribute::Private* const Akonadi::AddressAttribute::d’, can't use default assignment operator

The problem is assignment operator generated in sipakonadipart2.cpp - the "Private *const d" attribute cannot be changed in an assignment operator.

The question I cannot answer is if the "const" should/shouldn't be there, so that the assignment operator cannot/can exist.

Build log from Gentoo build process attached.

If you need more info, please tell me. Putting this to "High" as it doesn't compile, so pykde4 cannot be used on my system.

Reproducible: Always
Comment 1 Oldřich Jedlička 2010-07-15 06:48:39 UTC
Created attachment 49162 [details]
Build fix

This patch fixes the "operator=" problem by adding /NoDefaultCtors/ to SIP class definition.
Comment 2 Rex Dieter 2010-07-15 17:13:09 UTC
Created attachment 49179 [details]
define a placeholder = operator

Here's an alternative fix that defines a placeholder = operator.  Take your pick. :)
Comment 3 Rex Dieter 2010-07-15 17:13:39 UTC
marking confirmed, saw this on fedora too.
Comment 4 Rex Dieter 2010-07-15 17:15:37 UTC
*** Bug 244646 has been marked as a duplicate of this bug. ***
Comment 5 Simon Edwards 2010-07-15 22:37:43 UTC
I just committed a fix on trunk (r1150375), 4.5 and 4.4 branches.
Comment 6 Kevin Kofler 2010-07-19 00:09:29 UTC
Just to add some detail for anyone wondering what happened. (I guess none of what I'm about to explain will be new to Simon Edwards, but other people might want to know as well. :-) ) This change to SIP:
http://www.riverbankcomputing.com/hg/sip/rev/3e647ed0f2a2
is what triggered the problem. In the offending class, the constructor indeed has default arguments for everything. So the new SIP decides to build "assignment helpers", as for any default-constructable class. The problem is that the class is not actually assignable: there's no explicit operator= and the default one cannot be generated due to the const member.

One way to solve the problem would have been to just make the class assignable, but this requires changing kdepimlibs. One would have to change the const Private *d to a QSharedDataPointer<Private> d. But I don't know whether that is binary-compatible nor wheter it is desirable in the first place. We shouldn't have to change kdepimlibs to make the bindings work.

So what I did to fix the problem (I was the one who wrote the Fedora fix Rex Dieter attached in comment #2) is to add an artificial private operator= to addressattribute.sip. This marks the class as non-assignable in SIP and prevents SIP from generating assignment helpers, without other side effects. (I suspect NoDefaultCtors, which was suggested as an alternative fix, does have side effects!) I see this (the private operator=) is the fix that was committed upstream as per comment #5.

Thanks for resolving this in the upstream tree so quickly!