Please be aware that the KDE Frameworks are most definitely a work in progress - so build failures to come up as modules are enabled, rearranged and have code ported to take account of changes in Qt.

bcooksley wrote:Please be aware that the KDE Frameworks are most definitely a work in progress - so build failures to come up as modules are enabled, rearranged and have code ported to take account of changes in Qt.

I am aware that it is unstable, I'm just trying to see what I can get away with.

I recently got it to build, but I end up with some unresolved symbols when I try to run it, even when ldd reports that the core kde and qt libraries are the ones I rebuilt. Is there a reason why it's compiling undefined symbols. It seems nm is reporting lots of them in libkdeui.so, and my LD_LIBRARY_PATH is the same as the build one.

I can't find any more documentation, but does kdelibs need more compile options, then the prefix? Or do I need to rebuild the programs too?

Thanks.

This is primarily what I was referring to. libkdeui is one of the main libraries which is subject to changes as part of the Frameworks effort. I'm not sure if it will exist after the efforts are completed (if it does, it will be much smaller than before, or just containing compatibility classes)

bcooksley wrote:This is primarily what I was referring to. libkdeui is one of the main libraries which is subject to changes as part of the Frameworks effort. I'm not sure if it will exist after the efforts are completed (if it does, it will be much smaller than before, or just containing compatibility classes)

OK. maybe I'll try to rebuild kdebase programs and see if they run against the rebuilt kdelibs. I just find it wierd that it would actually compile with undefined symbols... I thought it would fail on the compile if that something was undefined.

The Frameworks will likely only work with kde-runtime at best at this stage. The changes are so significant that it is unlikely normal KDE applications will compile without either source or build system changes.

bcooksley wrote:The Frameworks will likely only work with kde-runtime at best at this stage. The changes are so significant that it is unlikely normal KDE applications will compile without either source or build system changes.

OK. I hope you don't mind me asking, I know it's unstable and all, but It seems that not even the utilities that come with kdelibs when you build them, like kjscmd in /usr/local/bin (kdelibs prefix is /usr/local) run now that I check. They get symbol errors too. (I would've thought it would end up a compile error?)

It also seems to install some stuff into the default /usr prefix, as even when LD_LIBRARY_PATH is unset, kde apps no longer work. Could this be the reason why? If the install process is going into /usr as well as /usr/local that I set, could it be not overwriting existing libraries, leaving the old ones?

(BTW: I'm not complaining about system breakerage when I say KDE apps fail, as this is only within a chroot that I rebuild)


But thanks so much for your time already!

It is quite probable that KJS and it's associated utilities have not yet been ported as part of the Frameworks. The effort is very much still in progress. I am not sure why things are being installed into /usr however when you have specified a different install prefix.

Are you aware which files are being installed into /usr?

bcooksley wrote:It is quite probable that KJS and it's associated utilities have not yet been ported as part of the Frameworks. The effort is very much still in progress. I am not sure why things are being installed into /usr however when you have specified a different install prefix.

Are you aware which files are being installed into /usr?

I don't know, all I really know is that its preventing kde apps from running... I tried grep-ing the build log, and I didn't see any lines saying that it is. Looking at ldd when I unset LD_LIBRARY_PATH, it seems some kde libararies are being replaced with the ones in /usr/local, and so it can't find the QT libraries in /usr/local... Maybe it's configuring some conf file?

As for kjscmd, it's being built with the frameworks package. If it wasn't ported yet, and using functions that are no longer in kdelibs, I would assume it would fail to compile, but it compiles?

It is probable that some parts of kjscmd are functioning - but for most of it's functionality it needs to load a library, which is either changed by the Frameworks work (and thus now incompatible) or it is loading your system wide libraries for some reason.

Perhaps you may want to try a different prefix other than /usr/local?

Thanks. I tried /opt instead of /usr/local, and now KDE apps run when I don't set LD_LIBRARY_PATH for the new kdelibs again.

As for the executing, it seems that when it compiled, it could be using the old version of QT. I can't be sure, but it said something about /usr/bin/qmake, and there is no /opt/bin/qmake. But I am going to try something first.

nerdopolis wrote:Thanks. I tried /opt instead of /usr/local, and now KDE apps run when I don't set LD_LIBRARY_PATH for the new kdelibs again.

As for the executing, it seems that when it compiled, it could be using the old version of QT. I can't be sure, but it said something about /usr/bin/qmake, and there is no /opt/bin/qmake. But I am going to try something first.

I tried a lighthouse version of QT 4.8 instead of QT 5. the build still fails. When I try QT 5, it now fails saying I should pass --reduce-exports to QT. I try that and it still fails with the same message.

I'll probably wait a month or so, maybe Frameworks will be buildable then. I can wait, it's fine.