[Marble-devel] What's new in KReport & KProperty & Predicate

[Dennis Nienhüser]

Hi Jaroslaw,

Am 24.05.2015 00:10, schrieb Jaroslaw Staniek:
> On 23 May 2015 at 15:39, Dennis Nienhüser <earthwings at gentoo.org> 
> wrote:
>> Hi Jaroslaw,
>> 
>> Am 23.05.2015 00:43, schrieb Jaroslaw Staniek:
> The only thing I noticed: on install it ignores that lib64/ is the
> right destination on my x86-64:
> 
> -- Installing: /home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.0.21.20
> -- Up-to-date: /home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.22
> -- Up-to-date: /home/jarek/dev/inst5/lib/libmarblewidget-qt5.so
> -- Removed runtime path from
> "/home/jarek/dev/inst5/lib/libmarblewidget-qt5.so.0.21.20"
> 
> I had to cd lib/; cp -R * ../lib64/.
> The RUNPATH is OK though, e.g.:
> 
> % readelf -d `which marble` | grep RUN
> 0x000000000000001d (RUNPATH)            Library runpath:
> [/home/jarek/dev/inst5/lib64]

when running the same here I don't have a RUNPATH entry. I'm wondering 
whether our software stack (cmake, kf5, ecm) behaves differently or 
whether something in your build environment is different to mine. Are 
you building Marble standalone or via some wrapper that compiles 
multiple projects at the same time?

I can reproduce a RUNPATH entry when I add --enable-new-dtags to the 
linker flags (like KDECompilerSettings.cmake does), however it does not 
end up with a 64 suffix. I'm working on a x86_64 as well. If I pass 
-DLIB_SUFFIX=64 as another cmake option, I end up with the same RUNPATH 
entry as you, however it does install correctly to lib64. LIB_SUFFIX is 
a cmake option added by Marble.

My goal for now is to understand why things end up differently on our 
systems, and then fix it to reach a consistent installation. One quick 
fix would be to use ECM globally in Marble, with the nice side-effect of 
reducing our CMakeLists.txt complexity further. This needs to be 
discussed in the Marble community first however as ECM would become a 
mandatory build-time dependency (Marble does not depend on KDE software 
so far, just Qt. Maybe we can blur that a bit now that KF5 is there as 
'thin Qt addons'). The alternative is to mimick KDE behavior manually in 
our cmake files, which is prone to end up with subtle differences like 
the above.

Regards,
Dennis