{"id":1663,"date":"2022-08-30T15:18:24","date_gmt":"2022-08-30T15:18:24","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/11\/27\/why-undefined-reference-when-the-variable-is-defined-and-the-library-is-linked-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:18:24","modified_gmt":"2022-08-30T15:18:24","slug":"why-undefined-reference-when-the-variable-is-defined-and-the-library-is-linked-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/why-undefined-reference-when-the-variable-is-defined-and-the-library-is-linked-collection-of-common-programming-errors\/","title":{"rendered":"Why “undefined reference” when the variable is defined and the library is linked?-Collection of common programming errors"},"content":{"rendered":"

Real problem in short:<\/strong> Circular library dependency between arch<\/code> and synergy<\/code>. Also, base<\/code> actually wasn’t linked to common<\/code> library (in the CMakeLists.txt for base<\/code>).<\/p>\n

Interestingly, this was caused by a configuration problem in the CMakeLists.txt files for the libraries. This had nothing to do with the CMakeLists.txt for the new synergyd<\/code> application I had added.<\/p>\n

The problem was that I did not link the libraries to each other where new calls were added to classes in other libraries. However, it seems that there is now a problem with circular linking.<\/p>\n

For example, I could have added…<\/p>\n

if (UNIX)\n    target_link_libraries(arch synergy)\nendif()\n<\/code><\/pre>\n
… to CMakeLists.txt in the arch<\/code> library, as arch<\/code> now calls something in the synergy<\/code> library. But this is invalid, since synergy<\/code> already calls something in arch<\/code>.<\/p>\n
Apparently this doesn’t matter on Windows.<\/p>\n
I’m not quite sure though what caused this to start happening, as it’s all old code that has been compiling fine before, and still does in other applications. I suspect most likely something to do with the recent removal of boiler plate from CArch, rather than something that CDaemonApp is doing (or maybe even a combination of both).<\/p>\n
Update<\/h2>\n
Just in case anyone cares \ud83d\ude09 — I think it is something to do with the relation between the lousy circular library dependency between arch<\/code> and synergy<\/code>, combined with the fact that CDaemonApp.cpp<\/code> wasn’t including CApp.h<\/code> — meaning that it was included at some other point, causing the weird undefined reference errors.<\/p>\n
To solve this properly, I have removed the circular dependency, which appeared to be the core of the problem.<\/p>\n
Update 2<\/h2>\n
The code now fully compiles, hurrah!<\/p>\n
I was still seeing one last error (the topic of this question):<\/p>\n
[ 90%] Building CXX object src\/cmd\/synergyd\/CMakeFiles\/synergyd.dir\/synergyd.o\nLinking CXX executable ..\/..\/..\/..\/..\/bin\/debug\/synergyd\n..\/..\/..\/..\/..\/lib\/debug\/libbase.a(CLog.o): In function `CLog::insert(ILogOutputter*, bool)':\n\/home\/nick\/Projects\/synergy\/branches\/1.4\/src\/lib\/base\/CLog.cpp:213: undefined reference to `kAppVersion'\ncollect2: ld returned 1 exit status\nmake[2]: *** [..\/..\/bin\/debug\/synergyd] Error 1\nmake[1]: *** [src\/cmd\/synergyd\/CMakeFiles\/synergyd.dir\/all] Error 2\nmake: *** [all] Error 2\n<\/code><\/pre>\n
This was simply caused by the base<\/code> library not linking to the common<\/code> library. Adding the following code to the CMakeLists.txt file for base fixed this:<\/p>\n
if (UNIX)\n    target_link_libraries(base common)\nendif()\n<\/code><\/pre>\n
Still not sure exactly why this started happening, just glad it’s fixed.<\/p>\n
Update 3<\/h2>\n
And here’s the commit: r1354<\/p>\n
Originally posted 2013-11-27 12:25:57. <\/small><\/p>","protected":false},"excerpt":{"rendered":"
Real problem in short: Circular library dependency between arch and synergy. Also, base actually wasn’t linked to common library (in the CMakeLists.txt for base). Interestingly, this was caused by a configuration problem in the CMakeLists.txt files for the libraries. This had nothing to do with the CMakeLists.txt for the new synergyd application I had added. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1663","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1663","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=1663"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1663\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=1663"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=1663"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=1663"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}