historic_bruno

(Or if you're not on Windows, see BuildInstructions which gives further instructions on building the game from SVN)

At least one of them is my old laptop

Which revision fixed this?

We need info about your system, can you post the game's system_info.txt from the log directory (see see GameDataPaths)? It should tell us your OS, graphics card, drivers, etc. It may be no more than a driver bug. Was it broken that way from the first install? Did you change any graphics settings before testing? You can reset them by deleting the user.cfg/local.cfg config files (see GameDataPaths).

Is this SVN (which revision) or release (which version)? Is it reproducible, or does it only happen rarely? If it's SVN and reproducible, you might try deleting the cache (see GameDataPaths), though that seems an unlikely solution. I have seen glitches on mines before (#2064) - also with preferglsl true. See what happens if you use only default config (no preferglsl/whizzbang graphics). That can at least direct us to a particular renderer path. Please make a Trac ticket and provide all information, so it doesn't get lost on the forum: http://trac.wildfiregames.com/wiki/ReportingErrors

It's too bad SpiderMonkey isn't interested in backward compatibility (though, who is really surprised?), that is really the only argument that matters. If they started requiring clang tomorrow, we would have to as well, I suppose Everything else is only justifying that necessity.

So... which one does it work for, the admin? We need more information to make sense out of this.

You're trying it with different users? Does it work for the user who downloaded and installed it? Do the users have different permissions, is one administrator and another not? Maybe you need to tell Gatekeeper to allow the app for each user?

The ticket for this is an old one: #198

update-workspaces.sh doesn't build the 0 A.D. sources What you're seeing is a compiler bug during the Spidermonkey build (which nobody else has reported), so without more information, it's particular to your system.

About this and the message from IRC, I disabled a few optional parts of wxWidgets that we didn't use in order to speed up the build a little, so feel free to add that back in.

Note that CPPFLAGS isn't C++ flags (as I once mistakenly assumed), it's actually the C preprocessor flags, so sometimes it does what you intended but not always. There's almost no reason to use it though. For C++ compiler flags, you actually want CXXFLAGS; most of build-osx-libs.sh has been changed to reflect that, but I guess NSPR and ICU were merged in from Git branches that had an older revision of build-osx-libs.sh. If you could make those changes, it would be nice and might even fix the need to flag libstdc++ manually there Other than that, the patch seems to be reasonable changes. Don't worry about the pre-10.7 build, as: 1) it's too few users to spend much time on, 2) it's broken anyway due to a bug in Spidermonkey. The 10.7 build is one that IMO we should still care about, it should take much less effort for it to work compared with, say, 10.6. I don't see anything in the patch that would break it irreparably, so it's only a matter of someone with 10.7 testing and possibly fixing the build, if they want. Once Yosemite (10.10) is released, that should be even less of a concern. You can try upgrading wxWidgets to 3.0.1 as was done in SVN, it should fix the Atlas crash on OS X. Once you have a bundle you're happy with, I would check the binaries (pyrogenesis, libAtlasUI.dylib, libCollada.dylib) with "otool -L binaryname", to see if it's pulling in any unexpected libs. Someone with a "clean" system (no Xcode or command line tools) should test the bundle on Mountain Lion and Mavericks if those are what we'll be supporting, to catch any unpleasant surprises, but a lot can be inferred from otool.

If Atlas crashes on Linux, you should provide a new error report (if you haven't already). This particular bug is different and doesn't go away when restarting.

There are far too many Linux distros for that to be practical

There's a Trac spam filter installed now, but I don't think it's working optimally. One problem with having to manually approve access is that people typically come to wikis to contribute in their own free time as a service to the community, and the more obstacles there are, the less motivated they will be. For example, the SDL wiki required (maybe still does) contacting the admin and explaining why you want an account there. All I wanted to do was complete some documentation while I was thinking about it, but it took days to be approved.

Atlas is broken on Macs in the old version (A15), it's a known problem. A16 hasn't been released for Macs yet.

Have you tried doing an svn cleanup ? If that doesn't work, you could try deleting binaries/system and re-updating.

The patch should be attached to the ticket (#2338), it was already requested but there was no reply. We can review it and verify if it fixes a bug (even if it's not the worst or only bug, that's better than nothing). We can work around both bugs if necessary: don't bundle Atlas (pass --disable-atlas to update-workspaces.sh, or leave out the libAtlasUI.dylib, so it doesn't simply crash) and don't use UPnP. I think the wxWidgets/Atlas bug is going to be harder to fix properly, unless they update 3.0 or we downgrade to 2.9.4. But doing nothing would be bad

The original crash here is the same as #2333 and should be fixed in r15269.

Should be fixed by r15269.

Also keep in mind there are still a few OS X release blockers: Atlas crashes due to a wxWidgets bug and multiplayer is likely to crash due to a bug in UPnP support.

Great Also, I think we can release a 10.8 or 10.9 only bundle, since it is already late. Unless you have the time and interest, 10.7 compatibility may have to wait (and pre-10.7 is practically a lost cause at this point). It seems like Mavericks adoption has been pretty good, it's a free upgrade after all...

Check that libxml2 built with the correct iconv, in particular you said you renamed the iconv folder, so maybe xml2-config is still pointing to the old path (see the FCollada section of build-osx-libs.sh and also libxml2 in extern_libs4.lua). You can try running libraries/osx/libxml2/bin/xml2-config --libs (or --cflags) to see if the paths are correct.

Linking, or fixing all the missing parts in extern_libs4.lua? It shouldn't be using the iconv from the SDK, but the one built in build-osx-libs. Seems like it doesn't have the paths set up properly (I don't know if the char** vs const char** issue would still exist if it built the correct version, but that is where the HAVE_ICONV_CONST define is relevant) as explained above.

Thanks for the crash log! At least that crash looks the same as #2333, which has been around for some time, but always hard to reproduce. I think the cause has been found, I will test and commit for A17 if so