Page 3 of 4

Re: Linking failed libfreeorioncommon.so

Posted: Sat May 09, 2015 8:13 pm
by Dilvish
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 [email protected] to [email protected], 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

Re: Linking failed libfreeorioncommon.so

Posted: Sat May 09, 2015 8:20 pm
by Dilvish
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.

Re: Linking failed libfreeorioncommon.so

Posted: Sun May 10, 2015 3:06 am
by adesst
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

[[email protected] 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
 )
[[email protected] freeorion]$ make clean
[[email protected] freeorion]$ git status -s | egrep "^\?\?" | awk '{print $2}' | xargs rm -rf
[[email protected] freeorion]$ ccmake .
[[email protected] freeorion]$ make VERBOSE=1
Successful, Linking CXX shared library libfreeorioncommon.so. Anyone could confirm this?
*) CMakeCache.txt attached.

Re: Linking failed libfreeorioncommon.so

Posted: Sun May 10, 2015 8:41 am
by Vezzra
Please forgive my ignorance, but what exactly is the difference between "in-source" and "out-of-source" builds? Just curious... ;)

Re: Linking failed libfreeorioncommon.so

Posted: Sun May 10, 2015 8:55 am
by adrian_broher
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/

Re: Linking failed libfreeorioncommon.so

Posted: Sun May 10, 2015 1:02 pm
by Vezzra
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?

Re: Linking failed libfreeorioncommon.so

Posted: Thu May 14, 2015 6:00 pm
by bigeagle
putting util/XMLDoc.cpp at the end worked for me

Re: Linking failed libfreeorioncommon.so

Posted: Thu May 14, 2015 6:08 pm
by Dilvish
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.

Re: Linking failed libfreeorioncommon.so

Posted: Sat May 16, 2015 4:36 pm
by adesst
bigeagle wrote:putting util/XMLDoc.cpp at the end worked for me
May i know what boost version are you using?

Re: Linking failed libfreeorioncommon.so

Posted: Tue May 19, 2015 9:35 pm
by Single Player
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.

Re: Linking failed libfreeorioncommon.so

Posted: Wed May 20, 2015 2:38 am
by Dilvish
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.

Re: Linking failed libfreeorioncommon.so

Posted: Wed May 20, 2015 6:51 pm
by Single Player
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.

Re: Linking failed libfreeorioncommon.so

Posted: Tue May 26, 2015 12:00 pm
by marcOSX
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.

Re: Linking failed libfreeorioncommon.so

Posted: Tue May 26, 2015 5:22 pm
by Dilvish
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?

Re: Linking failed libfreeorioncommon.so

Posted: Tue May 26, 2015 10:15 pm
by marcOSX
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.