[PyKDE] PyKDE and KDE 3.4.0
jbublitz at nwinternet.com
Thu Mar 3 20:45:28 GMT 2005
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
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.
More information about the PyQt