Best place to ask questions - Getting started on compiling

[Stu]

Hello All,
My girlfriend & I have gotten quite hooked on warzone lately, and now I'm trying to get it to compile so I can work on all the feature requests I'm getting from her

Hopefully I can get them to work, and they should be pretty useful for people in general as well, for example:
- letting the host allow users to pause a LAN game - obviously not defaulted to on, but handy for super-friendly games
- saving multiplayer games
- etc.

Anyways, so I'm still working through getting it to compile. I did read the guide, but it seems a bit out of date (e.g. - from reading the code - I don't think flex and bison are used anymore?)

Currently stuck on the fact that, while I downloaded, installed, and set the include path for QT - I don't have a QApplication file (not just that VS2010 can't find it - it does not exist).
After googling around, and looking at the QT creator pro files for some sample code - this may be because I'm using QT 5, and I'm downloading QT 4 right now. If someone knows the answer, though - let me know! I have set the include paths, the file is just not there.

But, more importantly:
- where is the best place to send questions to? I tried - info [at] developer dot wz2001 . net - but got a failure notice. So now I'm trying this.
- I am signed up on the list - and saw something about QT5 not being supported on Mac - should I always stick with QT4 ?
- I've only worked with QT on linux before - and now I'm developing with VS2010 (pro) and will eventually need to get it to compile on the mac (for my gf). Any general advice about using it on windows would be appreciated.
- yes, I pulled from git
- Any other general advice about development? Cultural/traditions I should know about the warzone dev community?

Thanks!

Take care,
-stu

[vexed]

Master branch don't need bison & flex anymore, that is correct. 3.x still uses it.
QT 4 is required for all branches, but, we will migrate to Qt5, as soon as we work out how to replace the deprecated functions.
Since you mention you have a mac available, perhaps you can make Qt5 builds for the mac, for us, when that process is complete.

For VS2010, when you get all the include files, and libs installed, it should be a matter of putting everything in the devpkg directory, and once you tell VS2010 where Qt is, it should compile without issue.

Technically, pausing the game is possible, since that is what it does (aka Zzz symbol), but saving the game state would be rather difficult at the current point in time.

Forums are usually the best place to ask, someone is around (usually), but, everyone is really busy, hence the lack of activity.
The ML is ... well... dead for the most part. Maybe 1 message a month, if that. We basically use the forums for everything, and IRC as well.

[Lord Apocalypse]

Last time I compiled it didn't ask for QT and ran fine. Does it need the path within VC?

[Stu]

Thanks for the help!

I already did get a little further with QT4..

Now, I've got a new dilemma

A couple files are including unistd.h under win32. I can move them into an else branch of the macro, and it gets a little further. But not sure if this will just bite me later.

I was wondering if unistd.h is included under win32 because most people compiling with ming & cygwin ?
Will I make things unnecessarily hard on myself using VS2010 ?
Or will it be a useful exercise ?
Or perhaps there is a unistd.h for windows that everyone uses?

Thanks!

Take care,
-stu

[Lord Apocalypse]

unistd is part of mingw and not used in windows. Just post the problems you run across and someone should be able to help.

On a side note the windows build is cross compiled on a linux box if memory serves and not directly compiled in windows. There may be some handy links in my compile thread from oh so long ago. viewtopic.php?f=6&t=9459 Hope it helps. May keep you from running into a lot of the same problems I did.

[vexed]

For unistd.h

Code: Select all

/*
 * This file is part of the Mingw32 package.
 *
 * unistd.h maps (roughly) to io.h
 */

#ifndef __STRICT_ANSI__

#include <io.h>
#include <process.h>

#endif 

MSVC looks for $(Qtdir) so that needs to be set in the system environment. (That means, set QTDIR to where you installed Qt to).

[Stu]

Thanks!

After reading the comments and the linked thread, it sounds like I should try cross-compiling for windows on linux.
I do have a linux desktop that is at least as powerful as my windows laptop, and I'll need to have it compiling for the girlfriends fairly old macbook anyway (which, if I can cross-compile for, rather than setting up yet another build for mac, should make things easier).

And it sounds like I'll do less damage to the codebase that way, and will have a greater probability of ending up with something useful to the community (since that is how the official builds work). I'll keep the thread updated with my progress or lack thereof.

Although if this is a completely way-off conclusion, let me know..

-stu

[vexed]

I can compile the game on MSVC 2010 with no issues.
If you want, you can do the cross-compiler route though.

[Lord Apocalypse]

The cross-compile for the project I believe is more of an issue with not having someone able to maintain the windows work, that and it seems easier to do it that way.

[Stu]

Ok! So now I have my first cross-compile question

I compiled the linux build on linux just fine, went very smoothly (except for a warning about my phyfs package being on tick too old, and that could cause issues, but it compiled and ran).

I'm not sure what configure flags I should be using for cross-compiling though...

I tried (with the mingw-w64 package installed, ubuntu):

$> ./configure --host=i686-w64-mingw32

And it stops with:

checking for nearbyint in -lm... no
configure: error: nearbyint not found

I also tried adding the CFLAGS and CXXFLAGS found on the wiki for windows cross-compiling (left out the PKG_CONFIG variable, though, it seemed unecessary, I couldn't figure where to point it anyways):

http://developer.wz2100.net/wiki/Compil ... dows/Cross

But I got the same error (and the guide seems to be geared toward someone compiling on windows for windows?)
I didn't try the installer flags, since I'm just trying to do one step at a time.

Since the linux compile worked fine, and I have a man page for nearbyint, and it appears to be part of the standard c library.. I'm guessing I'm just not pointing the right thing to the right place.. but beyond that, it's got me stumped for now.. I did find it interesting that the configure script appears to have comments indicating they are specifically trying to avoid the stdc implementation of nearbyint, but maybe I just read that wrong.

Btw, if I understand the build correctly, I can't cross-compile for a mac on linux? Or can I? I have access to a mac...

Take care,
-stu

[Stu]

Ok, after fiddling around with windows and linux more...

I realized I'm a dork, and the instructions here:

http://developer.wz2100.net/wiki/Compil ... dows/Cross

Are indeed for compiling for windows on linux (for some reason I read the title as compiling for windows on windows via ming).

I followed them, and it's making much more sense - the make command on step 3 worked, and I verified that it said "build" for things like qt and physics fs.

The only thing is now the configure script is complaining about qt not being installed.
Note that the linux build (with no options to configure) works fine - but I believe for cross-compiling, the configure script needs to point at the qt in the mingw-cross-env, not the qt-dev files installed by the package manager.

I used the same configure command as the guide specifies, with my mingw-cross-env path updated for my system, and I even tried setting a "QTDIR" env variable to:

[full path]/mingw-cross-env/mxe/usr/i686-pc-mingw32/qt

But the configure script still can't find QT.
If anyone knows what variable/arguments I need to pass to the configure script so it can find the qt that was built in the mingw-cross-env, that would be great!

Otherwise, I'll keep playing, and update the thread with results...

Take care,
-stu

[Stu]

Ok.. sooo.. close, and pretty sure it's not just me now.
Figured out the solution to the previous problem: the qt mxe *.pc directory was not in the PKG_CONFIG_PATH... and the PKG_CONFIG_PATH used was non-standard, so this:

$> export PKG_CONFIG_PATH_i686_pc_mingw32=/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/lib/pkgconfig/:/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/qt/lib/pkgconfig/

solved my problem.

After that, I had to unset SDL_CONFIG, because it failed on the final step (this was totally my bad, it was left set while I was trying to figure out the above).

Now I'm almost there, but the build fails with:

liphlpapi -lz -lintl -liconv -liberty -lstdc++
/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/lib/libOpenAL32.a(helpers.obj):helpers.c:(.rdata+0x14c): multiple definition of `IID_IDirectSoundNotify'
/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/lib/libdxguid.a(dxguid.o):dxguid.c:(.rdata+0x2080): first defined here
collect2: error: ld returned 1 exit status
make[3]: *** [warzone2100.exe] Error 1

And this looks like it may be a valid bug:

http://comments.gmane.org/gmane.comp.li ... devel/3410

http://buildbot.wz2100.net/builders/mas ... logs/stdio

Any idea on how I can follow/workaround this bug?
I'll try resync'ing to the latest git, but I didn't see anything pop up on trac recently.. so I thought I'd follow up here.

Take care,
-stu

[vexed]

Now I'm almost there, but the build fails with:

liphlpapi -lz -lintl -liconv -liberty -lstdc++
/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/lib/libOpenAL32.a(helpers.obj):helpers.c:(.rdata+0x14c): multiple definition of `IID_IDirectSoundNotify'
/home/stu/Projects/warzone/warzone2100/mingw-cross-env/mxe/usr/i686-pc-mingw32/lib/libdxguid.a(dxguid.o):dxguid.c:(.rdata+0x2080): first defined here
collect2: error: ld returned 1 exit status
make[3]: *** [warzone2100.exe] Error 1

And this looks like it may be a valid bug:


Any idea on how I can follow/workaround this bug?
I'll try resync'ing to the latest git, but I didn't see anything pop up on trac recently.. so I thought I'd follow up here.

Take care,
-stu

No, if you look at the latest buildbot builds, you would see that this isn't a issue.
The problem is how openAL was built. (Don't use DX)
Fix that, and the problem is solved.

[Stu]

Thanks!
But.. hmm.. I assumed that this means don't build it with dsound linked into openal.
But the only place I can see to control this (since the mxe build pulls openal down via wget, if I understand correctly), is:

src/openal-1-fixes.patch

But everytime I edit that patch, the build fails with Hunk errors.. not sure how to accomplish not using DX.
I did refresh the warzone with git, but since this is in the mxe code.... not sure what to do. I have a feeling there is a better way than directly editing the openal patch?

[vexed]

I thought it was a ./configure option...