Building tundra problems

[Alvin]

Hi all,

When I first build tundra solution, I met the linking error can't open "libboost_thread-vc90-mt-1_40.lib". But after I put "deps-vs2008-x86\boost\stage\lib' and "deps-vs2008-x86\boost\bin.v2\libs\thread\build\msvc-9.0\release\link-static\threading-multi" into linker, there are many new errors. Such as below:

14>Linking...

14>   Creating library C:\Users\qhe.CSE-PC114\Desktop\naali-tundra2\src\Core\TundraProtocolModule\RelWithDebInfo\TundraProtocolModule.lib and object C:\Users\qhe.CSE-PC114\Desktop\naali-tundra2\src\Core\TundraProtocolModule\RelWithDebInfo\TundraProtocolModule.exp

14>Client.obj : error LNK2019: unresolved external symbol "public: unsigned long __thiscall kNet::DataSerializer::AddSignedFixedPoint(int,int,float)" (?AddSignedFixedPoint@DataSerializer@kNet@@QAEKHHM@Z) referenced in function "public: void __thiscall TundraLogic::Client::GetCameraOrientation(void)" (?GetCameraOrientation@Client@TundraLogic@@QAEXXZ)

14>SyncManager.obj : error LNK2001: unresolved external symbol "public: unsigned long __thiscall kNet::DataSerializer::AddSignedFixedPoint(int,int,float)" (?AddSignedFixedPoint@DataSerializer@kNet@@QAEKHHM@Z)

14>KristalliProtocolModule.obj : error LNK2019: unresolved external symbol "public: __thiscall kNet::NetworkDialog::NetworkDialog(class QWidget *,class kNet::Network *)" (??0NetworkDialog@kNet@@QAE@PAVQWidget@@PAVNetwork@1@@Z) referenced in function "public: void __thiscall KristalliProtocolModule::OpenKNetLogWindow(void)" (?OpenKNetLogWindow@KristalliProtocolModule@@QAEXXZ)

........

14>C:\Users\qhe.CSE-PC114\Desktop\naali-tundra2\src\Core\TundraProtocolModule\RelWithDebInfo\TundraProtocolModule.dll : fatal error LNK1120: 12 unresolved externals

14>Build log was saved at "file://c:\Users\qhe.CSE-PC114\Desktop\naali-tundra2\src\Core\TundraProtocolModule\TundraProtocolModule.dir\RelWithDebInfo\BuildLog.htm"

14>TundraProtocolModule - 14 error(s), 3 warning(s)

========== Rebuild All: 13 succeeded, 1 failed, 0 skipped ==========

How to solve my problems? I'm going crazy... Thank you very very much!

[Ali Kämäräinen]

Did you execute <Tundra>\tools\Windows\VS2008\BuildDeps_RelWithDebInfo.cmd successfully before trying to build Tundra?

--
--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org
---
You received this message because you are subscribed to the Google Groups "realXtend-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to realxtend-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alvin]

Thank you for your reply.

I remembered there may be some warnings. I just run the ".cmd" file directly. Do I need to modify something in the ".cmd" file?

在 2014年1月6日星期一UTC+2下午11时23分37秒，JaakkoAllander写道：

[Jonne Nauha]

If you could run the CMake CMake_VS2008.bat again and read the boost and knet parts in there. If they are found correctly. You might need to increase the command prompts buffer size so you wont lose text as it finishes, or after a while hit ctrl+c to halt the run so you can read it.

Is this the only build error you get on the whole Tundra build? If boost/knet cannot be found pretty much all the modules should fail, so is it only TundraProtocolModule not finding the deps? All of them aquire the deps via the same path so this also seems improbable. Also we don't define the boost libs to link against on windows, it uses auto linking via lib pragmas (afaik).

In fact the default Tundra build should not use boost for anything anymore. It might be that your Tundra is no longer using boost, but your kNet build uses boost and hence tries to auto link to them. In this case I would try to delete the deps-vs2008-x86/knet directory and run the <Tundra>\tools\Windows\VS2008\BuildDeps_RelWithDebInfo.cmd deps build script again. Remember this script needs to be ran in a Visual Studio 2008 command prompt, not in a normal cmd.exe.

If you have build your dependencies before we changed tundra not to use boost, you have two options:

1. Enable boost back in <tundra>\CMakeLists.txt by setting TUNDRA_NO_BOOST to FALSE or 0 (zero) 
2. or delete anything that uses boost in our dependencies and rebuild them. A lot of things optionally use boost in our deps so to be sure, I would remove all folders except: qt, qtscriptgenerator, qt-solutions, qxmpp, qjson. So essentially anything starting with Qt. This will save you ~1-2 hours on the build, the rest should be pretty snappy :)

Let us know how it goes.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

[Alvin]

Thank you so much! 

Another problem is "2>LINK : fatal error LNK1104: cannot open file 'kNet.lib'". I copied "NaaliDepsSVN\bin\build_deps\kNet\lib" into kNet deps. Now I will try to set TUNDRA_NO_BOOST to FALSE or 0 (zero). If it not works, I will try to delete the deps-vs2008-x86/knet and run the "BuildDeps_RelWithDebInfo.cmd deps" build script. 

So you mean kNet and boost are not necessary?

在 2014年1月8日星期三UTC+2上午11时41分36秒，Jonne Nauha写道：

[Ali Kämäräinen]

NaaliDepsSVN? The SVN deps repository is ancient and haven't used for couple years. Have you build Tundra earlier (a very long time ago) and now trying to update and rebuild it? I would recommend doing a clean git checkout of the Tundra repository (still unfortunately named as "naali"), then opening VS 2008 cmd prompt and running the tools\Windows\VS2008\BuildDeps_RelWithDebInfo.cmd.

[Alvin]

It's because I don't know how to solve the "cannot open file 'kNet.lib'" error. So I copied the kNet libs.

I download the naali-tundra2.zip from https://github.com/realXtend/naali. Is this the newest one? 

在 2014年1月8日星期三UTC+2下午7时04分21秒，JaakkoAllander写道：

[Ali Kämäräinen]

I guess the zip should be ok. Have you read the README.md and the build instructions of the BuildDeps batch and set up everything? How does your <Tundra>\deps-vs2008-x86 directory look like? It should have the following content if every dependency has been at least downloaded ok:

assimp
boost
bullet
celt
kNet
ogg
ogre-safe-nocrashes
OpenAL
openssl
protobuf
qjson
qt
qtscriptgenerator
qt-solutions
qxmpp
realxtend-tundra-deps
speex
theora
websocketpp
vorbis
zlib
zziplib
boost_1_49_0.zip
jom_1_0_11.zip
protobuf-2.4.1.zip
qt-everywhere-opensource-src-4.8.5.zip
openssl-0.9.8x.tar.gz
zlib-1.2.8.tar.gz
zziplib-0.13.59.tar.bz2

[Jonne Nauha]

Yeah understand you might try to quick fix the problem by copying "any" knet.lib you can find to fix the problem but even if it links correctly you'll probably crash during runtime if you use something old :)

The current build flow does not use anything pre-compiled. There is the build .cmd script that I guess you now started to use or re-ran. If you have a old tundra git repo clone that you recently updated to the latest code, I would recommend you start everything from the beginning. We have changed the code base structure a lot and the build system has been completely rewamped. If nothing else helps, make a fresh git clone to a new location and start from the beginning. Read the README.md compiling from sources carefully until you understand it fully. It's not that complex but get a clear picture how to proceed and verify you have the needed tools in PATH so you can run a clean build without errors.

kNet is absolutely needed. Boost is no longer used as a "core dependency" by default. You can still enable boost as a "core framework" but that is not recommended for normal users (some of us core devs might want to play with it still). The thing that was changed is that boost is no longer required to build other dependencies like kNet, ogre, assimp and many many others. 

TL;DR I'm sure you can get it into a working state if you do a new clean clone of the Tundra repo and follow the README.md build instructions to the letter. A lot of things have changed recently about the build system which makes this the best option if you had a old fork/deps laying around.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

["Lasse Öörni"]

> It's because I don't know how to solve the "cannot open file 'kNet.lib'"
> error. So I copied the kNet libs.

I noticed something odd with kNet while building Tundra dependencies from
scratch. The file kNet/include/kNet/qt/ui/ui_Graph.h would not get
generated although the UI file kNet/ui/Graph.ui is there, so building kNet
would fail.

kNet stable branch itself hasn't been updated since May last year, so I
suspect this could be due to changes/bugs in CMake recent version(s).

A workaround would be to build kNet without Qt UI (debugging dialogs)
support.

--
Lasse ��rni
Game Programmer
LudoCraft Ltd.

[Alvin]

Yes, I have all of these. But when I build tundra.sln, there is still the error "2>LINK : fatal error LNK1104: cannot open file 'kNet.lib'".

Have you ever encountered such a problem?

在 2014年1月8日星期三UTC+2下午7时52分32秒，JaakkoAllander写道：

[Alvin]

I have built from the beginning again. But the kNet problem still can't be solved.

You mean boost is no longer used as a "core dependency" by default. So how to build without it?

在 2014年1月9日星期四UTC+2上午9时52分08秒，Jonne Nauha写道：

[Ali Kämäräinen]

As Lasse mentioned, there might some recently surfaced bug related to newer CMake versions? What version are you using BTW (cmake --version will tell that)? Anyways, open up tools\Windows\BuildDeps.cmd and find the following line:
"cmake . -G %GENERATOR% -DBOOST_ROOT=%BOOST_ROOT% -DUSE_BOOST:BOOL=%USE_BOOST% -DUSE_TINYXML:BOOL=FALSE -DUSE_QT:BOOL=TRUE"
Change the "-DUSE_QT:BOOL=TRUE" to "-DUSE_QT:BOOL=FALSE" and try rerunning the VS2008\BuildDeps_RelWithDebInfo.cmd.

[Alvin]

I noticed this problem this time. How to build kNet without Qt UI?  Could you tell me more details?

在 2014年1月9日星期四UTC+2上午11时01分37秒，Lasse Öörni写道：

Lasse ��rni
Game Programmer
LudoCraft Ltd.

[Alvin]

I'm using the cmake version "cmake-2.8.12-win32-x86". 

I'll try your method. Thank you very very much.

在 2014年1月9日星期四UTC+2上午11时19分28秒，JaakkoAllander写道：

[Jonne Nauha]

CMake has recently prepared itself to be Qt5 ready. I suspect this stuff is probably due to it. The old Qt4 stuff should still work (what we use in Tundra), but knet might use some more generic Qt macros and hence fail to find the moccing tool or something like that :( We should investigate, fix and send a pull request for Clb.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

[Erno Kuusela]

On Thu, Jan 09, 2014 at 01:19:52AM -0800, Alvin wrote:
| I noticed this problem this time. How to build kNet without Qt UI? Could
| you tell me more details?

Changing -DUSE_QT:BOOL=TRUE to -DUSE_QT:BOOL=FALSE in BuildDeps.cmd
should do the trick.

(Disclaimer: I haven't used the Windows build scripts)

[Ali Kämäräinen]

Yes Erno, like I already mentioned 4 messages ago. ;)

[Alvin]

Thanks a lot!!

I'm now running the "BuildDeps_RelWithDebInfo.cmd" file. Wish a good result.

在 2014年1月9日星期四UTC+2下午12时10分36秒，Erno Kuusela写道：

[Alvin]

It works now. A lot thanks to Jaakko, Erno and Jonne!!! 

The result is "Build: 30 succeeded, 0 failed, 2 up-to-date, 1 skipped".

I'll continue to work on it.

Thanks a lot to all of you!!!

在 2014年1月9日星期四UTC+2下午12时12分06秒，JaakkoAllander写道：

[Jonne Nauha]

Yeah, thanks for the feedback. We should fix this asap for all platforms, so Qt is not used for kNet. This is totally optional. Only thing you will get extra in Tundra is a network profiling widget in the Tundra profiler. It is detected via the knet qt preprocessor macro so no code changes are neccesary either.

Let us know if you have other questions while working on the tundra codebase :)

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com