kdevplatform tries to link a static lib into a shared lib...

[Alexander Neundorf]

On Tuesday 21 August 2007 06:03, Andreas Pakulat wrote:
> On 20.08.07 23:57:08, Alexander Neundorf wrote:
> > On Sunday 19 August 2007 16:22, Andreas Pakulat wrote:
> > > 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.
> >
> > Do I understand correctly that a static library is linked into a shared
> > library in the hope that it will work as a libtool convenience library ?
>
> Basically yes (the static lib is linked into a plugin)
>
> > Please don't do this, this doesn't work on all platforms, sooner or later
> > there will be problems. Just use the source files directly.
>
> No, the right solution is to make it a shared lib but there's nobody
> with the time for that at the moment. If you have a suggestion how to
> disable the plugin for all 64 bit I can quickly workaround the current
> build-problems on such systems (its not working on win32 anyway).

Is the problem detecting the 64bit build ?
You could check CMAKE_SIZEOF_VOID_P ?
Of if some of the lib paths contain 64.
Maybe also CMAKE_SYSTEM_PROCESSOR, but that's not really reliable I think.

Bye
Alex