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

... 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.

-- 
David Faure, faurekde.org, sponsored by Trolltech to work on
KDE,
Konqueror (http://www.konqueror.org
), and KOffice (http://www.koffice.org).

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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 ?
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.

Bye
Alex

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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).

As I said: We are aware of the problem and it will be fixed
before the
KDevelop4.0 release.

Andreas

-- 
You are always busy.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

-----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/YEYvJPQf2q7hBrTDDQCf
cipL
wRqjTxGuCySMWkk0CTV41YI=
=dyia
-----END PGP SIGNATURE-----

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 21.08.07 07:53:57, Alexander Neundorf wrote:
> On Tuesday 21 August 2007 06:03, Andreas Pakulat
wrote:
> > On 20.08.07 23:57:08, Alexander Neundorf wrote:
> > > 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.

The problem is I have no idea how to check for 32 or 64 bit
system
during cmake-time, so I could do something like

if(32bit)
  add_directory(teamwork)
endif(32bit)

I don't know what to fill in instead of 32bit and I didn't
have the time
to go hunting for something yet.

Andreas

-- 
Cheer Up!  Things are getting worse at a slower rate.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Tuesday 21 August 2007 08:03, Andreas Pakulat wrote:
> On 21.08.07 07:53:57, Alexander Neundorf wrote:
> > On Tuesday 21 August 2007 06:03, Andreas Pakulat
wrote:
> > > On 20.08.07 23:57:08, Alexander Neundorf
wrote:
> > > > 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.
>
> The problem is I have no idea how to check for 32 or 64
bit system
> during cmake-time, so I could do something like
>

something like the following should do:
if(NOT CMAKE_SIZEOF_VOID_P EQUAL 8)

(what about 64bit Mac or other platforms with 64bit ?)

> if(32bit)
>   add_directory(teamwork)
> endif(32bit)

Bye
Alex

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 21.08.07 20:38:11, Alexander Neundorf wrote:
> On Tuesday 21 August 2007 08:03, Andreas Pakulat
wrote:
> > On 21.08.07 07:53:57, Alexander Neundorf wrote:
> > > On Tuesday 21 August 2007 06:03, Andreas
Pakulat wrote:
> > > > On 20.08.07 23:57:08, Alexander Neundorf
wrote:
> > > > > 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.
> >
> > The problem is I have no idea how to check for 32
or 64 bit system
> > during cmake-time, so I could do something like
> >
> 
> something like the following should do:
> if(NOT CMAKE_SIZEOF_VOID_P EQUAL 8)

That evaluates to true on 32 Bit systems right? (Just
double-checking)

> (what about 64bit Mac or other platforms with 64bit ?)

No idea to be honest. Win64 is not really a problem (and
neither is
win32) as its not ported to that platform yet (the
dependecies don't
exist).

Andreas

-- 
Chess tonight.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 22 August 2007 02:40, Andreas Pakulat wrote:
> On 21.08.07 20:38:11, Alexander Neundorf wrote:
> > On Tuesday 21 August 2007 08:03, Andreas Pakulat
wrote:
> > > On 21.08.07 07:53:57, Alexander Neundorf
wrote:
> > > > On Tuesday 21 August 2007 06:03, Andreas
Pakulat wrote:
> > > > > On 20.08.07 23:57:08, Alexander
Neundorf wrote:
> > > > > > 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.
> > >
> > > The problem is I have no idea how to check
for 32 or 64 bit system
> > > during cmake-time, so I could do something
like
> >
> > something like the following should do:
> > if(NOT CMAKE_SIZEOF_VOID_P EQUAL 8)
>
> That evaluates to true on 32 Bit systems right? (Just
double-checking)

Yes (beside that I didn't test this line).

Bye
Alex

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel