Linking failed libfreeorioncommon.so

Questions, problems and discussion about compiling FreeOrion.
Message
Author
User avatar
Dilvish
AI Lead, Programmer
Posts: 4720
Joined: Sat Sep 22, 2012 6:25 pm

Re: Linking failed libfreeorioncommon.so

#31 Post by Dilvish » Sat May 09, 2015 8:13 pm

Single Player wrote:Can all of you confirm that you normally do out-of-source builds? Has anybody succeeded building from inside source tree?
up until a few months ago, when we switched the repo from SVN@SourceForge to git@GitHub, I used to always do my builds in the source tree, without problem. But I had to keep several different source trees for the different things I was working on. Now with git I find it much much more convenient to just work with a single source tree and do out-of source builds.

trying right now building in the source-tree, I also get the versionstring errors, using cmake version 2.8.11.2
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
Dilvish
AI Lead, Programmer
Posts: 4720
Joined: Sat Sep 22, 2012 6:25 pm

Re: Linking failed libfreeorioncommon.so

#32 Post by Dilvish » Sat May 09, 2015 8:20 pm

update, in light of adests comment about -j, I tried rerunning make as just plain make, and that by itself did not solve the problem. But then I reran cmake and again ran make, and then it finished up fine.
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

#33 Post by adesst » Sun May 10, 2015 3:06 am

Dilvish wrote:update, in light of adests comment about -j, I tried rerunning make as just plain make, and that by itself did not solve the problem. But then I reran cmake and again ran make, and then it finished up fine.
I clean everything and remake just to confirm that modifying CMakeList.txt would solved the
`undefined reference FreeOrionVersionString` error.

Code: Select all

[adesanto@localhost freeorion]$ git diff CMakeLists.txt
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
 )
[adesanto@localhost freeorion]$ make clean
[adesanto@localhost freeorion]$ git status -s | egrep "^\?\?" | awk '{print $2}' | xargs rm -rf
[adesanto@localhost freeorion]$ ccmake .
[adesanto@localhost freeorion]$ make VERBOSE=1
Successful, Linking CXX shared library libfreeorioncommon.so. Anyone could confirm this?
*) CMakeCache.txt attached.
Attachments
CMakeCache.txt
(39.17 KiB) Downloaded 63 times

User avatar
Vezzra
Release Manager, Design
Posts: 4677
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Linking failed libfreeorioncommon.so

#34 Post by Vezzra » Sun May 10, 2015 8:41 am

Please forgive my ignorance, but what exactly is the difference between "in-source" and "out-of-source" builds? Just curious... ;)

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

Re: Linking failed libfreeorioncommon.so

#35 Post by adrian_broher » Sun May 10, 2015 8:55 am

Vezzra wrote:Please forgive my ignorance, but what exactly is the difference between "in-source" and "out-of-source" builds? Just curious... ;)
in-source: You call cmake within the git directory (source directory). Intermediate files and build products are placed inside the source directory.

$ ls
freeorion.git
$ cd freeorion.git
$ cmake .
$ make

out-of-source: You create a dedicated build directory outside of the git directory. Intermediate files and build products are placed within the build directory.

$ ls
freeorion.git
$ mkdir freeorion.gcc
$ ls
freeorion.git
freeorion.gcc
$ cd freeorion.gcc
$ cmake ../freeorion.git
$ make

http://voices.canonical.com/jussi.pakka ... rectories/
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 4677
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Linking failed libfreeorioncommon.so

#36 Post by Vezzra » Sun May 10, 2015 1:02 pm

Ah, ok, that cleared things up for me.

Well, in that case I can see why there might be issues with version.cpp. But I'd rather expect them with out-of-source builds... no?

bigeagle
Krill Swarm
Posts: 10
Joined: Mon May 11, 2015 12:10 pm

Re: Linking failed libfreeorioncommon.so

#37 Post by bigeagle » Thu May 14, 2015 6:00 pm

putting util/XMLDoc.cpp at the end worked for me

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

Re: Linking failed libfreeorioncommon.so

#38 Post by Dilvish » Thu May 14, 2015 6:08 pm

bigeagle wrote:putting util/XMLDoc.cpp at the end worked for me
It seems an odd solution, but it's worked for enough people that I've committed it into master now.
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

#39 Post by adesst » Sat May 16, 2015 4:36 pm

bigeagle wrote:putting util/XMLDoc.cpp at the end worked for me
May i know what boost version are you using?

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

Re: Linking failed libfreeorioncommon.so

#40 Post by Single Player » Tue May 19, 2015 9:35 pm

adesst wrote:
Dilvish wrote:update, in light of adests comment about -j, I tried rerunning make as just plain make, and that by itself did not solve the problem. But then I reran cmake and again ran make, and then it finished up fine.
I clean everything and remake just to confirm that modifying CMakeList.txt would solved the
`undefined reference FreeOrionVersionString` error.
I tried several times (also just today with current sources), all with make -j 1 and with cmake 2.8.12.2 and 3.2.2 and cleaned up with 'git clean -f -d -x' in between - no luck. All builds failed with this error.

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

Re: Linking failed libfreeorioncommon.so

#41 Post by Dilvish » Wed May 20, 2015 2:38 am

Single Player wrote:cleaned up with 'git clean -f -d -x' in between - no luck. All builds failed with this error.
Just to check, you have pulled the recent code as well (which has the CMakeLists.txt fix/hack in it)?

Also, I take it this recurring error is still just for an in-source build, yes? It looks like you previously reported that an out-of-source build solved the problem for you.
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

#42 Post by Single Player » Wed May 20, 2015 6:51 pm

Dilvish wrote:
Single Player wrote:cleaned up with 'git clean -f -d -x' in between - no luck. All builds failed with this error.
Just to check, you have pulled the recent code as well (which has the CMakeLists.txt fix/hack in it)?
Yes to both.
Dilvish wrote:Also, I take it this recurring error is still just for an in-source build, yes? It looks like you previously reported that an out-of-source build solved the problem for you.
Exactly - out-of-source builds work just fine. There have been no problems with them since I first tried at adrian_broher's suggestion.
I just rebuilt (a little bit late) to test/report if the CMakeLists.txt reordering worked fo me.

marcOSX
Space Squid
Posts: 55
Joined: Sat May 31, 2014 5:20 pm

Re: Linking failed libfreeorioncommon.so

#43 Post by marcOSX » Tue May 26, 2015 12:00 pm

Hello,

Thank you all for your tips. I just compiled a perfectly working freeorion test built from geit updated master on Ubuntu 14.04 trusty. I had previously the `FreeOrionVersionString()' warnings, referring to some missing libs (requisites are not up to date in the compile in linux page), but everything ended up working with an out-of-source compile.

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

Re: Linking failed libfreeorioncommon.so

#44 Post by Dilvish » Tue May 26, 2015 5:22 pm

marcOSX wrote:warnings, referring to some missing libs (requisites are not up to date in the compile in linux page)
Could you save me a bit of time, and let me know what specifically was not up to date?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

marcOSX
Space Squid
Posts: 55
Joined: Sat May 31, 2014 5:20 pm

Re: Linking failed libfreeorioncommon.so

#45 Post by marcOSX » Tue May 26, 2015 10:15 pm

Dilvish wrote:Could you save me a bit of time, and let me know what specifically was not up to date?
I would love to but I had not taken notes at the time. I will try to explain what I remember. First of all, I was doing that in a pretty vanilla install of trusty, as I had not set yet a complete development environment.

I did as explained there in the Ubuntu section, but with updated libs in some cases as if I remember well it is now libtiff5-dev. I built my own bullet which compiled smoothly.

Then when compiling freeorion, I got diffrent pauses and had to install different libs. Each one I identified in the logs but the message I mostly remember is "pthreads not found" because I realized that I had quite some crucial libs missing. So on that point on I went on updating all my libc, c++, python addons dev libs and graphic libs. So I installed probably much more that was specifically required by freeorion, so that I could also compile my other favorite software.

After a last ldconfig, "rm CMake.cache", "make clean" && make, the binary was there neat and clean, ready for a "make install" (I think this obvious step is also missing in the page) and it installed perfectly under /usr/local and is running well.

I am sorry not being able to be acurrate and specific. I will check if some of the logs survived some of my make clean, but now the needed libraries are installed (among others) and it will be difficult to reproduce each step.

Post Reply