[KDE/Mac] Fixes for Filelight utility and LSkat game
nicos at macports.org
Fri May 9 17:31:59 UTC 2014
On May9, 2014, at 22:42, Ian Wadham <iandw.au at gmail.com> wrote:
> Thanks for the offer, Nicolas. But I don't think I would know what to do with
> the Portfiles. I am a very run-of-the-mill MacPorts *user* - not in any sense
> a MacPorts developer.
I don’t think it would be really required to play around with Portfiles, as I think I
should have them sorted to a major extent up to kde4-baseapps (so not the extension
packages *-utils, *-games and so on, but they are usually easier if the base is there).
It would essentially just require to set up a local repository, which is supposedly simple:
and then use the new Portfiles to install the ports while using the existing
Macports libraries, which may solve some of your issues.
> On Apple OS X, I keep running into this problem where the same library
> is in both /usr/ and /opt/local/ and some libraries are only in one or the other.
> I am relying on MacPorts to provide most of the dependencies and libraries.
> So I set -DCMAKE_PREFIX_PATH=/opt/local for CMake, but some KDE modules
> require -DCMAKE_PREFIX_PATH=/opt/local:/usr and even then CMake
> sometimes seems to pick up from /usr when the same thing is in MacPorts.
Yes, I am not completely sure about how CMake works on this matter, but I think
there are also default places where it looks for libraries. I experienced cases where
I found simpler to just hardcode the path of the libraries I wanted to use instead of
trying to deactivate the unwanted paths in the find_* macros.
> There is also a non-portability in baloo, which I patched around (malloc_trim()
> is not in /usr/ - it is a GNU extension).
Yes, I had missed the reviewboard link you provided later in the mailing list, and also
had filed a ticket about it: https://bugs.kde.org/show_bug.cgi?id=333874.
> Currently kde-runtime, kde-workspace and kde-baseapps fail to build.
> kde-runtime is getting a linker error in kglobalaccel (keystroke and shortcuts
> Linking CXX executable kglobalaccel
> Undefined symbols for architecture x86_64:
> "GlobalShortcutsRegistry::keyPressed(int)", referenced from:
> hotKeyEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) in kglobalaccel_mac.o
> KGlobalAccelImpl::keyPressed(int) in kglobalaccel_mac.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
This error is not KDE 4.13 specific, we had it for some time (I think it appeared at
4.12). There is a fix in Macports to circumvent it. However, it is not a simple patch, but
a post-configure hack, which can be applied manually, although it may be cumbersome.
> Note that I have a MacPorts installation that I use for everyday activity
> so I do not want to risk messing that up.
If you don’t need them simultaneously you could keep the two installation around,
and use activate/deactivate commands to have the one you want at a given time.
For simultaneous use, having two separate Macports tree may also be possible,
but it is signing for trouble in my experience.
> I also have KDE code which I develop in a special area and it is linking to
> MacPorts kdelibs4 for KDE 4.12 ATM. The kdesrc-build thing is in yet
> another special area.
> Is the problem with kde-runtime easily solved? If not, is
> there some way I could set up a separate MacPorts and build
> KDE 4.13 stuff? Where would MacPorts get the source from?
As Macports keeps the inactive ports around, you could surely have
both, which could be just activated/deactivated depending on the need,
which just implies some files copies. Portfiles also use various KDE
repositories to get the sources, and the Portfiles I have are set for the
new sources tarballs.
More information about the kde-mac