[PyKDE] PyKDE and KDE 3.4.0

[Jim Bublitz]

On Thursday 03 March 2005 10:25, Simon Edwards wrote:
> On Thursday 03 March 2005 17:15, Jim Bublitz wrote:
> > I guess I'm not up to speed on this issue. Is this the __attribute__
> > stuff?
>
> maybe, symbol visibility means you can hide C++ symbols in shared
> libraries. i.e. private symbols are hidden from users of the library.

Yeah - they seem to be using *_NOEXPORT [__attribute__ (visibility 
("hidden"))] and *_EXPORT  [__attribute__ (visibility ("default"))] macros.

> > What's the change between gcc 3.3.4 (which is what I used) and 3.4?
>
> nothing interesting for us. There is a visibility patch for 3.4 and gentoo
> has it. Visibility is being properly included in 3.5.
>
> > What kinds of problems are occurring?
>
> PyKDE wanting symbols that kdelibs doesn't export anymore.  Some of them
> were things that had to be fixed in kdelibs (i.e. bugs), others are cases
> where PyKDE binds private classes etc. I'm hoping that I've fixed all of
> them now, but it is hard to tell...

I'm no expert on this by any means, but my guess is it will be impossible to 
tell. I haven't looked real closely, but from a quick check, they're not 
using *_NOEXPORT but *_EXPORT instead and somehow setting "default" to 
indicate hidden or exported. I might be wrong, but otherwise I don't see how 
they're hiding anything, since *_NOEXPORT appears to be used in about 1 place 
(from grepping kdelibs source).

If that's the case, the "somehow" will be the real problem. It means that 
presip would have to be able to accomplish out the same "somehow", and while 
it does some rudimentary preprocessing, it isn't a full-blown compiler 
front-end. My concern is that "somehow" is in the Makefiles. Even if it's 
not, it opens the door for all kinds of variations between distributions, 
similar to things Mandrake and SuSE have done in the past.

Assuming the best case, it'll take a fair amount of work to modify presip and 
the process I use to take this into account. Right now I just do the 
equivalent of 

    #define KDE_EXPORT

when generating PyKDE.

The other alternative is to do what you're asking some users to do: try to 
compile and link and find out what's not exported. That's one 
compile/link/load per symbol. That's also a "best case" proposition, where 
"best case" means all distributions are the same.

Initially there was a lot of that to get PyKDE working because KDE has always 
defined symbols in h files that don't exist in the .so libs, and it's varied 
by distribution.  That used to be just about the most time consuming part of 
developing PyKDE - easily a 50 hours or more just to find missing symbols.

Another alternative is to manually go through the source code (3 or 4 times a 
year) - I wouldn't even consider that.

I hate to be a downer, but it looks like a long time before I'll be releasing 
gcc 3.4 compatible versions of PyKDE. Doesn't look encouraging.

Outside of the Mandrake-specific stuff, I could release a PyKDE for KDE 3.4.0 
within a day or two - IIRC there's one new method and some extended enums. I 
plan to get the %Feature stuff that Mandrake needs working in presip first 
and fix some other versioning problems, so it'll probably be more like a few 
weeks or more depending on how much time I can devote to it.

Jim