kdevplatform tries to link a static lib into a shared lib...
Andreas Pakulat
apaku at gmx.de
Sun Aug 19 20:22:39 UTC 2007
On 13.08.07 16:29:47, David Faure wrote:
> ... and that doesn't work, in particular on x86_64.
>
> Linking CXX shared module ../../lib/kdevteamwork.so
> /usr/bin/ld: /d/kde/build/4/kdevplatform/lib/libnetwork.a(message.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> /d/kde/build/4/kdevplatform/lib/libnetwork.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [lib/kdevteamwork.so] Error 1
> make[1]: *** [plugins/teamwork/CMakeFiles/kdevteamwork.dir/all] Error 2
> make: *** [all] Error 2
> makeobj[0]: Leaving directory `/d/kde/build/4/kdevplatform'
>
> libnetwork.a seems to be used only from plugins/teamwork/CMakeLists.txt, how about
> referencing the libnetwork files from there? Possibly using a var that is set by plugins/teamwork/CMakeLists.txt
> like we do in koffice/kdgantt/CMakeLists.txt.
> Or using a real shared library.
Neither nor, the only solution atm is disabling it on 64 bit systems,
but I don't know how to do that with cmake.
The reason we don't want the files to be referenced directly is to keep
the CMakeLists.txt clean and the library might (at some point) be
factored out as its a general-use-network lib. And it can't easily be
made a shared lib because only the original author can annotate the
classes with export macro's in a timely manner (i.e. without dozens of
days of trying what works and what doesn't) and he has no time atm
(GSoC).
We are aware of the issue and will fix it.
Andreas
--
Your step will soil many countries.
More information about the KDevelop-devel
mailing list