Package Details: warzone2100-git r13675.10b39fc53-1

Git Clone URL: https://aur.archlinux.org/warzone2100-git.git (read-only)
Package Base: warzone2100-git
Description: 3D realtime strategy game on a future Earth (Git version)
Upstream URL: http://wz2100.net/
Keywords: game
Licenses: GPL
Conflicts: warzone2100
Provides: warzone, warzone-svn, warzone2100, warzone2100-beta
Submitter: disastro
Maintainer: disastro
Last Packager: disastro
Votes: 7
Popularity: 0.456390
First Submitted: 2010-11-28 08:49
Last Updated: 2017-11-05 07:53

Latest Comments

EndlessEden commented on 2017-11-06 08:50

Disabled Debug works...
but there is a "Relaxed" option. that still builds with debug options, but ignores warnings.

Please consider this, and i use the debug ingame menu, for testing maps and changes, im pushing upstream.

---

Also, i was using native. I specified "Piledriver" in my comment instead of "bdver2", by mistake. i havent used the platform specific flag, in a long time. so i had forgotten.

I avoid Generic because i see a measurable 31% decrease in performance. As well as a 11% decrease from -O2, vs -03 or -fast. - Which may seem fine to you, but im working on a mod and every little bit helps...

disastro commented on 2017-11-05 07:40

Hello EndlessEden,
Me and a couple of people ran multiple builds of the package and couldn't replicate your build failure unfortunately.

The only time we could break the build on a different error was by using clang instead of clang++, so make sure your CXX is set to clang++. clang++ (03) worked with both debugging enabled or disabled while g++ still fails on that unitialized error if using O3 with debugging.

EDIT2: Actually seems it's just gcc that can't use piledriver because such mtune setting doesn't seem to exist? clang just ignores it?
(I could only test march=native or mtune=generic and couldn't test piledriver personally but the people on IRC did and it built fine for them even on clang++, with only -fno-plt as an extra CFLAG to yours.)

What I suggest based on the build error and our testbuilds is try with either g++ or mtune=generic although it's hard to say if that will fix anything since I am not sure of the other changes to your system. I want to remind you that Arch uses g++ and O2 by default so it's all extra if a package builds with special flags. That being said I am unsure why the CFLAGS, while unsupported, work on the system or two tried on IRC and not on yours.

EDIT: PS. Based on some of the discussions on IRC I've decided to --disable-debug for everyone and trust that the makepkg debugging build works if one enables it.

phillid commented on 2017-11-05 07:26

@EndlessEden, works for me with the same CFLAGS and CXXFLAGS, except I have -fno-plt hanging on the end of both. Just to cover my bases; you are running up-to-date Arch, right?

EndlessEden commented on 2017-11-05 05:40

"piedraw.cpp:79:61: error: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Werror,-Wnull-pointer-arithmetic]
glVertexAttribPointer(loc, size, type, normalised, stride, BUFFER_OFFSET(offset));
^~~~~~~~~~~~~~~~~~~~~
piedraw.cpp:47:40: note: expanded from macro 'BUFFER_OFFSET'
#define BUFFER_OFFSET(i) ((char *)NULL + (i))
~~~~~~~~~~~~ ^
mv -f .deps/piepalette.Tpo .deps/piepalette.Po
piedraw.cpp:240:69: error: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Werror,-Wnull-pointer-arithmetic]
glDrawElements(GL_TRIANGLES, shape->npolys * 3, GL_UNSIGNED_SHORT, BUFFER_OFFSET(frame * shape->npolys * 3 * sizeof(uint16_t)));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
piedraw.cpp:47:40: note: expanded from macro 'BUFFER_OFFSET'
#define BUFFER_OFFSET(i) ((char *)NULL + (i))
~~~~~~~~~~~~ ^
2 errors generated."

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=piledriver -O3 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=piledriver -O3 -pipe -fstack-protector-strong"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"

Compiler: Clang

Sigh... same issue.

disastro commented on 2017-11-03 15:38

PhysFS deprecated the usage of getUserDir so it uses getPrefDir that points to the platform correct directory like .local/share on Linux

EndlessEden commented on 2017-11-03 15:22

"EDIT: Almost forgot. The patch currently moves the save directory from ~/.warzone2100-master to ~/.local/share/.warzone2100-master"

Warzone2100 doesnt support loading from symlinks or non-standard locations. How did you overcome this?

disastro commented on 2017-11-03 13:19

Patch is done, package now builds again with the latest PhysFS Arch ships with.

There may still be a few bugs to iron out for instance there seems to be a lot of logspam when the game runs even though everything is working afaict.

Will have to investigate another day.

EDIT: Almost forgot. The patch currently moves the save directory from ~/.warzone2100-master to ~/.local/share/.warzone2100-master

disastro commented on 2017-11-03 08:56

@EndlessEden: You've failed to show me a build that fails with reasonable CFLAGS (without O4 for instance, which doesn't exist) and the error that results in. You could have reached out to me in here, with email or in IRC but no.

Currently all the package fails on for me are PhysFS deprecation errors as I noted below since PhysFS updated four days ago. I'm making a patch to fix them and we'll see if it builds after that again.

I am not sure what Android has to do with Arch or Warzone 2100, and last I heard the Qt backend was a bit broken. Warzone 2100 already uses Qt by default for what it can without any flags thus the dependency.

EndlessEden commented on 2017-11-03 01:42

@disastro: As ive said before. Ive attempted compilation of your package on more than 11 systems, 8 of which were stock, 3 of which the makepkg.conf contained optimisations for the system. all Updated with all the necessary packages for there system operation.

I keep repeatedly mentioning this issue, over and over. The only way this could be building without issue, is if there running in a chroot and significantly out of date. Ive attempted to reach a compromise, that doesnt require me to maintain a seperate branch on all 11 systems, but you refused to proper look into the issue. Again, if this issue is not occuring, why is it reproducible on all 11 machines?

Ive submitted a second package, with a changes ive requested, a backend change to QT, since SDL is not maintained on all platforms(ie:Android). I will maintain it seperate from your branch to include the experimental changes that are not on master. I would appreciate it, if you wouldnt request a duplicate removal, as this is not the case.

disastro commented on 2017-11-02 10:59

PhysFS updated to 3, currently building to check it works

All comments