kAppVersion is indeed defined in the common library, Version.o which appears to have built correctly. I am linking this to synergyd, so the base library should be using it.
> I'm trying to get this release out the door, but I'm stuck on this > compiler error. I figured someone else might see something obvious I'm > doing wrong!
> kAppVersion is indeed defined in the common library, Version.o which > appears to have built correctly. I am linking this to synergyd, so the > base library should be using it.
On 6 April 2012 00:53, Chris Schoeneman <cschoene...@gmail.com> wrote:
> Does CMakeLists.txt need to list target_link_libraries in dependency order? If so then 'common' must come before 'base'.
That's what I thought -- I tried reordering like this, but no effect. Then I tried cleaning and deleting all temporary files, but still same error. Then I checked the target_link_libraries for synergyc and synergys but interestingly common does not come before base (it goes: arch base client common ...), yet it still builds. Quite puzzling.
On 5 April 2012 11:47, Nick Bolton <nick.bolton...@gmail.com> wrote:
> I'm trying to get this release out the door, but I'm stuck on this > compiler error. I figured someone else might see something obvious I'm > doing wrong!
Last time I faced this type of error, it was due to a signature mismatch between 2 object codes: from one end the variable/method was an extern C, while on the other end it was C++. As c++ demangler is used on the symbol before printing the error message, nothing obvious pops in the linker error message...
-- Envoyé depuis mon Palm Pre
Le 6 avr. 2012 11:57, Nick Bolton <nick.bolton.uk@gmail.com> a écrit :
On 5 April 2012 11:47, Nick Bolton <nick.bolton.uk@gmail.com> wrote:
> I'm trying to get this release out the door, but I'm stuck on this
> compiler error. I figured someone else might see something obvious I'm
> doing wrong!
>
> http://buildbot.synergy-foss.org:8000/builders/1.4-linux32/builds/522/steps/compile/logs/stdio
Posted the question here with a bit more explanation:
While I was focusing on the CMakeLists.txt for synergyd, I was overlooking the CMakeLists.txt in the base lib. Also there was a circular dependency between the arch and synergy libraries, that I had apparently introduced a long time ago. Not sure why these issues have surfaced now, could be something to do with the recent change to CArch.cpp or the way that CDaemonApp was not including CApp.h the same as synergyc/synergys, but I'm really not sure.
That's possible but I don't see any extern "C" anywhere relevant. Nick, you could 'nm libcommon.a' and verify kAppVersion is defined there, appropriately mangled, and then 'nm libbase.a' to ensure it's undefined there, also mangled.
How about a verbose log of the error. That prints the command line, correct? If the library order is wrong there then cmake isn't using the right order and the problem is finding out why.
Incidentally, I got the required order exactly backwards: common must come after base. The linker discovers the missing symbol in base and looks for it in any library linked later, complaining only if the symbol isn't found anywhere. One thing you could try for kicks is to list common twice, maybe adding at again at the end in CMakeLists.txt. Having a static library twice has significance so hopefully cmake won't strip it and it'll link successfully. If so you can fool around with the library order until it works.
cheers, -chris
On Apr 6, 2012, at 5:07 AM, Francois-Xavier Kowalski wrote:
> Last time I faced this type of error, it was due to a signature mismatch between 2 object codes: from one end the variable/method was an extern C, while on the other end it was C++. As c++ demangler is used on the symbol before printing the error message, nothing obvious pops in the linker error message...
> -- Envoyé depuis mon Palm Pre
> Le 6 avr. 2012 11:57, Nick Bolton <nick.bolton...@gmail.com> a écrit :
> On 5 April 2012 11:47, Nick Bolton <nick.bolton...@gmail.com> wrote: > > I'm trying to get this release out the door, but I'm stuck on this > > compiler error. I figured someone else might see something obvious I'm > > doing wrong!
