Linking failed libfreeorioncommon.so

Questions, problems and discussion about compiling FreeOrion.

Moderator: Oberlus

Message
Author
User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Linking failed libfreeorioncommon.so

#16 Post by Dilvish »

Hmm, well that fix for getting Version.cpp.o likely means that my suggestion above will not help. But even if it doesn't, I'd be curious to hear if it gives you a more informative error message.

As for the nature of that fix, it's extra unpleasant if there is nothing we can do in our code to remedy it. Did they simply stop defining boost::archive::library_version_type (which was just and unsigned int anyway)? I see that in old boost code both of those structures for checking the library version appear to be used throughout the boost serialization code, but in the limited amount of 1.58 serialization code I looked it they check it in the way that doesn't require boost::archive::library_version_type.

Could one of you guys try something for me? go to util/Process.h and after

Code: Select all

#include <boost/serialization/shared_ptr.hpp>
add

Code: Select all

typedef unsigned int boost::archive::library_version_type;
and then see if you can compile without making that library version change to boost/Serialization/deque.cpp?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Single Player
Space Floater
Posts: 15
Joined: Sun Jul 06, 2014 7:24 pm

Re: Linking failed libfreeorioncommon.so

#17 Post by Single Player »

Dilvish wrote:I can't answer (at least for now) the main question of why this is happening, but try this:

go to your build directory and verify that it has a "util" directory that (only) contains "Version.cpp"; if this is not the case then make the directory and copy the file in. Then (again, from the build directory) run

Code: Select all

make util/Version.o
that should cause the necessary file to be generated in the correct location (CmakeFiles/freeorioncommon.dir/ like you had checked for)
I tried to do what you suggested by using a Version.cpp from a previous build and invoking a make rule that'd build a .o from it - to no avail. None of the generated makefiles (with whatever name) mention a "Version.cpp.o" or a compatible template as a target or "Version.cpp" as a source file.
I ended up modifying the (generated) build scripts to pick up "Version.cpp" - mimicking what's done for the code compiled and linked into libfreeorioncommon.so. I created a diff file with my edits and commented them a little bit. See occurrences of "[Single Player]..." :wink:
I'm completely new to cmake so I don't know what I did here but...

... the result "built fine" 8)
Attachments

[The extension diff has been deactivated and can no longer be displayed.]


User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Linking failed libfreeorioncommon.so

#18 Post by Dilvish »

Single Player wrote:... the result "built fine" 8)
Well, I am very glad to hear that.
I tried to do what you suggested by using a Version.cpp from a previous build and invoking a make rule that'd build a .o from it - to no avail.
Right, as I indicated in the post above, once I saw adesst clarify what he had to do to fix that problem, it seemed unlikely that the 'try to force Version.cpp.o" approach would work.

If you didn't yet try the method I proposed immediately above, about changing (in freeorion) util/Process.h, could you give that a try also, along with the standard CMake file (be sure to clear the cache)?

It's good to know you could clear it up by adjusting your cmake files, though I'll leave it to adrian_broher to decide what, if anything, to do with ours.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#19 Post by adesst »

Here is what i got when I modified the files as suggested:
1. restore boost/serialization/deque.hpp
2. util/Process.h and Serialize.ipp

Code: Select all

adesanto@xubuntu14:/opt/freeorion-1$ git diff util
diff --git a/util/Process.h b/util/Process.h
index f9927cc..299438d 100644
--- a/util/Process.h
+++ b/util/Process.h
@@ -14,8 +14,14 @@
 #include <boost/serialization/type_info_implementation.hpp> // This
 #endif
 
+#if BOOST_VERSION == 105800
+#include <boost/serialization/type_info_implementation.hpp> // This
+#include <boost/archive/basic_archive.hpp> // This
+#endif
+
 #include <boost/serialization/shared_ptr.hpp>
 
+
 #include <vector>
 #include <string>
 
diff --git a/util/Serialize.ipp b/util/Serialize.ipp
index b4027b2..d41086a 100644
--- a/util/Serialize.ipp
+++ b/util/Serialize.ipp
@@ -12,6 +12,11 @@
 #include <boost/serialization/extended_type_info.hpp> //This
 #endif
 
+#if BOOST_VERSION == 105800
+#include <boost/serialization/type_info_implementation.hpp> // This
+#include <boost/archive/basic_archive.hpp> // This
+#endif
+
 #include <boost/serialization/export.hpp>
 #include <boost/serialization/deque.hpp>
 #include <boost/serialization/list.hpp>
And i set GCC_FLAGS and C_FLAGS -DBOOST_VERSION=105800 using ccmake.
Stop with

Code: Select all

/usr/lib/icecc/bin/c++   -DBOOST_ALL_DYN_LINK -DENABLE_BINRELOC -DFREEORION_BUILD_HUMAN -DFREEORION_LINUX -DBOOST_VERSION=105800 -Wno-deprecated -Wall -Wno-parentheses -fvisibility=hidden -I/opt/freeorion/FreeOrion/boost_1_58_0 -I/opt/freeorion-1 -I/opt/freeorion-1/GG -I/usr/include/AL -I/opt/freeorion-1/PagedGeometry/include    -o CMakeFiles/freeorion.dir/__/__/UI/CombatReport/CombatReportWnd.cpp.o -c /opt/freeorion-1/UI/CombatReport/CombatReportWnd.cpp
In file included from /opt/freeorion-1/UI/CombatReport/CombatReportWnd.cpp:6:0:
/opt/freeorion/FreeOrion/boost_1_58_0/../universe/ShipDesign.h:81:36: error: expected ‘)’ before ‘type’
     FighterStats(CombatFighterType type,
                                    ^
/opt/freeorion/FreeOrion/boost_1_58_0/../universe/ShipDesign.h:92:5: error: ‘CombatFighterType’ does not name a type
     CombatFighterType   m_type;
     ^
In file included from /opt/freeorion/FreeOrion/boost_1_58_0/boost/serialization/binary_object.hpp:33:0,
                 from /opt/freeorion-1/GG/GG/Texture.h:38,
                 from /opt/freeorion-1/GG/GG/Font.h:37,
                 from /opt/freeorion-1/GG/GG/TextControl.h:34,
                 from /opt/freeorion-1/GG/GG/Button.h:35,
                 from /opt/freeorion/FreeOrion/boost_1_58_0/../UI/CUIWnd.h:6,
                 from /opt/freeorion-1/UI/CombatReport/CombatReportWnd.h:4,
                 from /opt/freeorion-1/UI/CombatReport/CombatReportWnd.cpp:1:
/opt/freeorion/FreeOrion/boost_1_58_0/../universe/ShipDesign.h: In member function ‘void FighterStats::serialize(Archive&, unsigned int)’:
/opt/freeorion/FreeOrion/boost_1_58_0/../universe/ShipDesign.h:105:39: error: ‘m_type’ was not declared in this scope
         ar  & BOOST_SERIALIZATION_NVP(m_type)
                                       ^
/opt/freeorion/FreeOrion/boost_1_58_0/boost/serialization/nvp.hpp:128:62: note: in definition of macro ‘BOOST_SERIALIZATION_NVP’
     boost::serialization::make_nvp(BOOST_PP_STRINGIZE(name), name)
                                                              ^
In file included from /opt/freeorion/FreeOrion/boost_1_58_0/boost/filesystem/path_traits.hpp:23:0,
                 from /opt/freeorion/FreeOrion/boost_1_58_0/boost/filesystem/path.hpp:25,
                 from /opt/freeorion-1/UI/CombatReport/../ClientUI.h:15,
                 from /opt/freeorion-1/UI/CombatReport/CombatReportWnd.cpp:2:
/opt/freeorion/FreeOrion/boost_1_58_0/boost/system/error_code.hpp: At global scope:
/opt/freeorion/FreeOrion/boost_1_58_0/boost/system/error_code.hpp:221:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable]
     static const error_category &  posix_category = generic_category();
                                    ^
/opt/freeorion/FreeOrion/boost_1_58_0/boost/system/error_code.hpp:222:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable]
     static const error_category &  errno_ecat     = generic_category();
                                    ^
/opt/freeorion/FreeOrion/boost_1_58_0/boost/system/error_code.hpp:223:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable]
     static const error_category &  native_ecat    = system_category();
                                    ^

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#20 Post by adesst »

Aha! I got it

it is just dir traverse.

Code: Select all

adesanto@xubuntu14:/opt/freeorion-1$ git diff  UI/CombatReport/CombatReportWnd.cpp
diff --git a/UI/CombatReport/CombatReportWnd.cpp b/UI/CombatReport/CombatReportWnd.cpp
index 39e374c..b4453ac 100644
--- a/UI/CombatReport/CombatReportWnd.cpp
+++ b/UI/CombatReport/CombatReportWnd.cpp
@@ -3,7 +3,7 @@
 #include "../CUIControls.h"
 #include "../../util/i18n.h"
 #include "../../util/Logger.h"
-#include "../universe/ShipDesign.h"
+#include "../../universe/ShipDesign.h"
 
 #include "CombatReportData.h"
 #include "GraphicalSummary.h"
Build complete!

Single Player
Space Floater
Posts: 15
Joined: Sun Jul 06, 2014 7:24 pm

Re: Linking failed libfreeorioncommon.so

#21 Post by Single Player »

Dilvish wrote:If you didn't yet try the method I proposed immediately above, about changing (in freeorion) util/Process.h, could you give that a try also, along with the standard CMake file (be sure to clear the cache)?
Well I didn't really need any modifications to or because of boost in the first place. My only problem seemed to be

Code: Select all

../libfreeorioncommon.so: undefined reference to `FreeOrionVersionString()'
when linking freeoriond against libfreeorioncommon.so. The changes in my patch file were the only ones I needed.
Did you suggest the util/Process.h edit instead of my build file adventures or both?
Dilvish wrote:It's good to know you could clear it up by adjusting your cmake files, though I'll leave it to adrian_broher to decide what, if anything, to do with ours.
Since I do not find modifications to the intermediate build files completely satisfactory I'll try to fiddle with the cmake documentation and see what I can do ;-)
Meanwhile just hardcoding the version string where FreeOrionVersionString() is referenced seems to be a way better workaround .

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Linking failed libfreeorioncommon.so

#22 Post by adrian_broher »

Dilvish wrote:I'll leave it to adrian_broher to decide what, if anything, to do with ours.
I will do nothing.

The way proposed to 'fix' this is out of our support scope.

I also can't reproduce the problem of Version.cpp missing from the build as part of freeorioncommon.so.

I can only suggest to clean up the git sources from build cruft `git clean -Xfd` and then to build out-of-source.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

Single Player
Space Floater
Posts: 15
Joined: Sun Jul 06, 2014 7:24 pm

Re: Linking failed libfreeorioncommon.so

#23 Post by Single Player »

adrian_broher wrote:
Dilvish wrote:I'll leave it to adrian_broher to decide what, if anything, to do with ours.
I will do nothing.

The way proposed to 'fix' this is out of our support scope.
Don't know if you meant my patch file. That was not something I'd dare to propose as a fix :wink: Only to show what I ended up doing to get that Version.cpp.o built and linked.
A fix would need understanding what really had to be fixed - and maybe only apply to my build setup.
adrian_broher wrote:I also can't reproduce the problem of Version.cpp missing from the build as part of freeorioncommon.so.
So could adesst. But this problem stays with me as mysteriously as it disappeared for him.
adrian_broher wrote:I can only suggest to clean up the git sources from build cruft `git clean -Xfd` and then to build out-of-source.
Or git clean -f -d -x (mind the lower case x). That's what I used. I'll try with a seperate source directory however.

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Linking failed libfreeorioncommon.so

#24 Post by adrian_broher »

Single Player wrote:Don't know if you meant my patch file. That was not something I'd dare to propose as a fix :wink: Only to show what I ended up doing to get that Version.cpp.o built and linked.
A fix would need understanding what really had to be fixed - and maybe only apply to my build setup.
Then I misinterpreted the purpose of the diff file you posted.
Single Player wrote:So could adesst. But this problem stays with me as mysteriously as it disappeared for him.
I rebuild from a clean source dir into a clean build dir and it is just not reproducible for me. You mentioned that you use CMake 3.0.2. I use 2.8.12.2, maybe this could be the cause, but I need to investigate that.
adrian_broher wrote:Or git clean -f -d -x (mind the lower case x). That's what I used. I'll try with a seperate source directory however.
Well, thanks for pointing that out. I assumed that the intermediate CMake build files were part of the .gitignore, which they are not. That's something I never realized, because I do out-of-source builds by habit.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

Single Player
Space Floater
Posts: 15
Joined: Sun Jul 06, 2014 7:24 pm

Re: Linking failed libfreeorioncommon.so

#25 Post by Single Player »

adrian_broher wrote:You mentioned that you use CMake 3.0.2. I use 2.8.12.2, maybe this could be the cause, but I need to investigate that.
Now that is interesting. I have tried to build with current cmake - 3.2.2 - that didn't work. An older version would be worth a try... But that has to wait a little - I need some sleep first.

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#26 Post by adesst »

Single Player wrote:
adrian_broher wrote:You mentioned that you use CMake 3.0.2. I use 2.8.12.2, maybe this could be the cause, but I need to investigate that.
Now that is interesting. I have tried to build with current cmake - 3.2.2 - that didn't work. An older version would be worth a try... But that has to wait a little - I need some sleep first.
I see why i dont see the error.

Code: Select all

adesanto@xubuntu14:~$ cmake --version
cmake version 2.8.12.2

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#27 Post by adesst »

@Single_player

I use ccmake 3.2.2 to build freeorion with no error.

Code: Select all

adesanto@xubuntu14:/opt/freeorion-1$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
adesanto@xubuntu14:/opt/freeorion-1$ /opt/CMake/bin/ccmake --version
ccmake version 3.2.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
adesanto@xubuntu14:/opt/freeorion-1$ 


And yes i compiled CMake from source

Code: Select all

adesanto@xubuntu14:/opt/CMake$ cat .git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = [email protected]:Kitware/CMake.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
	rebase = true

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#28 Post by adesst »

Building FreeOrion on Fedora19 64 has `FreeOrionVersionString()` error too.

Code: Select all

Linking CXX executable ../../freeorionca
cd /opt/c++/freeorion/client/AI && /usr/bin/cmake -E cmake_link_script CMakeFiles/freeorionca.dir/link.txt --verbose=1
/usr/libexec/icecc/bin/c++   -DBOOST_VERSION=105800 -Wno-deprecated -Wall -Wno-parentheses -fvisibility=hidden    CMakeFiles/freeorionca.dir/__/__/AI/AIInterface.cpp.o CMakeFiles/freeorionca.dir/AIClientApp.cpp.o CMakeFiles/freeorionca.dir/__/__/AI/PythonAI.cpp.o CMakeFiles/freeorionca.dir/camain.cpp.o CMakeFiles/freeorionca.dir/__/ClientApp.cpp.o CMakeFiles/freeorionca.dir/__/ClientFSMEvents.cpp.o CMakeFiles/freeorionca.dir/__/__/combat/CombatSystem.cpp.o CMakeFiles/freeorionca.dir/__/__/network/ClientNetworking.cpp.o CMakeFiles/freeorionca.dir/__/__/python/PythonEmpireWrapper.cpp.o CMakeFiles/freeorionca.dir/__/__/python/PythonEnumWrapper.cpp.o CMakeFiles/freeorionca.dir/__/__/python/PythonLoggingWrapper.cpp.o CMakeFiles/freeorionca.dir/__/__/python/PythonUniverseWrapper.cpp.o  -o ../../freeorionca -rdynamic ../../libfreeorioncommon.so ../../libfreeorionparse.so -lpython2.7 /opt/c++/boost_1_58_0/stage/lib/libboost_python-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_log-mt.so -lpthread /opt/c++/boost_1_58_0/stage/lib/libboost_chrono-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_date_time-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_filesystem-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_regex-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_serialization-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_signals-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_system-mt.so /opt/c++/boost_1_58_0/stage/lib/libboost_thread-mt.so -lz /opt/c++/boost_1_58_0/stage/lib/libboost_log-mt.so -Wl,-rpath,/opt/c++/freeorion:/opt/c++/boost_1_58_0/stage/lib:::::: 
../../libfreeorioncommon.so: undefined reference to `FreeOrionVersionString()'
collect2: error: ld returned 1 exit status

[adesanto@localhost freeorion]$ ccmake --version
ccmake version 2.8.12.2
[adesanto@localhost freeorion]$ make --version
GNU Make 3.82
Built for x86_64-redhat-linux-gnu
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[adesanto@localhost freeorion]$ /usr/bin/c++ --version
c++ (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
However i did a little change at CMakeLists.txt and run make with no -j option and the result FO build successful

Code: Select all

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 604c416..e26e204 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -236,8 +236,8 @@ set (freeorioncommon_SOURCE
     util/SitRepEntry.cpp
     util/StringTable.cpp
     util/VarText.cpp
-    util/XMLDoc.cpp
     util/Version.cpp
+    util/XMLDoc.cpp
 )
 
 if (NOT WIN32)

Single Player
Space Floater
Posts: 15
Joined: Sun Jul 06, 2014 7:24 pm

Re: Linking failed libfreeorioncommon.so

#29 Post by Single Player »

adrian_broher wrote:...That's something I never realized, because I do out-of-source builds by habit.
I just found out this does the trick. Without modifying the sources. And regardless of cmake version (I tried 2.8.12.2 and 3.2.2).

Can all of you confirm that you normally do out-of-source builds? Has anybody succeeded building from inside source tree?

If not the linux compilation page in the wiki should probably be changed.
It still seems to be based on (latest) SVN and describes in-source tree builds:
FreeOrionWiki/Compile In Linux wrote:cd freeorion/FreeOrion
cmake .
make
That did work then but doesn't now.

Thank you everybody for your patience!

adesst - was your failed attempt an in-source tree build?

User avatar
adesst
Space Floater
Posts: 18
Joined: Tue May 05, 2015 10:38 am

Re: Linking failed libfreeorioncommon.so

#30 Post by adesst »

adesst - was your failed attempt an in-source tree build?
Yes it was. And so the successful build in-source tree build.
I found out that the -j* options sometime break the build process.

Post Reply