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

[Matt Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 21, 2007, at 6:53 AM, Alexander Neundorf wrote:

> 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

Thanks for your suggestions. The problem is that nobody ported it  
correctly. We need for somebody to do it for us if they don't want to  
wait for us to fix it. Otherwise, we'll get to it when we can. You  
can also not build teamwork and then you won't see the problem.
- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFGytNYA6Vv5rghv0cRAldrAJwM3uZaUeZ/YEYvJPQf2q7hBrTDDQCfcipL
wRqjTxGuCySMWkk0CTV41YI=
=dyia
-----END PGP SIGNATURE-----