Yves

It should be sdl. Someone wrote a guide, but it's probably outdated and not final: http://trac.wildfiregames.com/wiki/MacBuildInstructions

I've attached the patch for working around the bus-error to Ticket #903.

No. It will only delete precompiled.h.gch if it needs to be rebuilt. As far as I understand, the file will be entirely rebuilt in this case anyway and there should be no disadvantages. I'm going to create a patch for that tomorrow, we can then test if everything works as expected.

I've installed the newest version of gcc (4.6.1) from source and this seems to fix it. I've compiled everything about 5 times without getting the bus-error then switched back to 4.4.5 and it happened every time again. Do you think manually deleting precompiled.h.gch every time before it rebuilds (like shown in the last post) is a valid workaround? I think we must find a workaround because a lot of users will be using a version of gcc with this bug. If you agree I can write a patch to include it in premake4.

Yes, that was the problem. I'm using Win7 64bit too and it wasn't needed here. Does anyone else have strange g++ errors when running the makefiles in parallel mode (e.g. make -j5)? I'm using Ubuntu's default version(4:4.4.4-1ubuntu2). g++: Internal error: Bus-Zugriffsfehler (program cc1plus) Please submit a full bug report. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. This happens on my Ubuntu, but I've never seen it on the Snow Leopard. EDIT: It's something related to pch. I've tried gcc 4.5 which had the same problem and put some "sleeps" into the makefile, but it didn't help either. I know exactly in which line it happens, but I don't know why... Steps to reproduce: 1. Build everything with make -j5 (no problems). 2. Do something that causes the precompiled headers to be rebuilt (e.g. add "extern int testxyz;" to status.h). 3. run make -j5 lowlevel or just make -j5. The relevant part including my tests with sleep: ifneq (,$(PCH)) $(GCH): $(PCH) | $(OBJDIR) @echo $(notdir $<) sleep 5 -$(SILENT) cp $< $(OBJDIR) sleep 5 $(SILENT) $(CXX) $(CXXFLAGS) -o "$@" -c "$<" sleep 5 endif and the output: yves@yves-desktop:~/Projekte/0ad/build/workspaces/gcc$ make -j5 lowlevel ==== Building lowlevel (release) ==== precompiled.h sleep 5 sleep 5 g++: Internal error: Bus-Zugriffsfehler (program cc1plus) Please submit a full bug report. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. make[1]: *** [obj/lowlevel_Release/precompiled.h.gch] Fehler 1 make: *** [lowlevel] Fehler 2 EDIT2: Deleting precompiled.h.gch seems to work around the problem somehow. I don't understand what's happening here. For me it looks like make and gcc are interfering somehow on precompiled.h.gch... but how? The relevant targets depend on $(GCH), so make should patiently wait until precompiled.h.gch is successfully updated before building them. Any Ideas? $(GCH): $(PCH) | $(OBJDIR) @echo $(notdir $<) rm -f $(OBJDIR)/precompiled.h.gch -$(SILENT) cp $< $(OBJDIR) $(SILENT) $(CXX) $(CXXFLAGS) -o "$@" -c "$<" endif EDIT3: Something else... I've closed ticket #428. Is that ok or should I ask next time before closing a ticket?

I'm back from holiday and will have some time for working on the remaining problems this week. Today I've looked into the path issues with cxxtestgen and also the patch by historic_bruno (thank you!). The root cause of the problem is that the relative path is relative to premake4.lua and not to the project files. In those environments using customizations of premake for test-generation, this is no problem because premake handles it internally. I'm suggesting a slightly different solution than historic_bruno which should keep working when moving premake4.lua or the project-directory and also is a bit more self-explaining in my opinion. I've also discovered that the makefiles use an absolute path to cxxtestgen which is not good. Accessing cxxtestpath via prj.cxxtestpath instead of prj.solution.cxxtestpath changes this. The changes from my previous patches are also included in this one. I've tested compiling on Linux, Mac and Windows. "premake4 embed" has already been done (script.c is included), but the prebuilt premake4.exe will have to be rebuilt and updated. Could someone please review and apply the patch? Btw. I couldn't start 0ad on windows because it always failed calling JS_CallFunctionName with the "init" function. Is this a known bug? pch_cxxtest_cleanworkspaces_v4.patch

Thank you for testing. It seems to be a similar problem as the relative path issue with precompiled headers. The directory structure was changed a little bit during the integration into svn (premake4.lua went up one level). That seems to be the reason why we get problems with parts of the code that don't handle paths correctly. I don't know if I have time to fix this one because I'm preparing for departure this evening. I'm going to be on holyday the next three weeks.

I like it. Probably the centre is a bit too "round" if you know what I mean. What do you think about making the lake less regular and removing some trees from on side?

Thank you! Would be interesting to know. It only cost about 5$ if I remember correctly. I would have done it if I had a "real" mac . Ok I hope this is the last and successful try, version 3 of the patch. It's quickly tested on Linux, Mac and Windows... if I wasn't too tired and made mistakes . Further testing appreciated! patch_pch_clean-workspaces_v3.txt

Well then my patch probably won't work on Windows. Changing pchheader from string to path also made some problems on linux. It looks like there's more testing and more work required...

Changing the type of pchheader from "string" to "path" in api.lua fixes the problem. I'm wondering why premake uses "path" for pchsource and "string" for pchheader. I'm going to integrate this change into the patch from the last post and add it as an attachment to this post. EDIT: Done, the new patch is up. patch_pch_clean-workspaces_v2.txt

Yes I've found the problem and I'm fixing it. EDIT: A patch is attached. Please test it because I didn't have much time for tests. It fixes ticket #903 and adds a command to clean-workspaces.sh for cleaning the premake4 environment. For testing don't forget to run clean-workspaces.sh. Question: Why do you even have a precompiled.cpp file? Shouldn't precompiled.h be sufficient? patch_pch_clean-workspaces.txt

The nasm-problem is a known issue and should be documented in the build instructions. XCode ships with an older version of nasm which does not support the macho64 flag. I've solved it on my system by replacing the nasm-binary of Xcode with a symbolic link to the newer one installed via macports. I'm not sure if that's a good solution though. EDIT: I can't reproduce ticket # 903. When I change something, it rebuilds the file. Did somebody already fix it? Ah I see, It's only when running make scriptinterface. It rebuilds properly if you just run make.

Thank you Philip! I'm glad it's committed now . EDIT: Btw. here are some tickets related to the update: 1. Ticket #404 Makefile build system should have pyrogenesis/test targets depend on Collada Status: It seems there's still no solution for this, but there's an existing feature-request for premake. 2. Ticket #428 Generated makefiles should not try to run wrong premake Status: I think this was already fixed in the most recent version of premake3, but definitely now with premake4. Can be closed. 3. Ticket #713 Update premake for Xcode use

http://www.golem.de/1107/84896.html

Hmm did I post a patch after yours? Am I getting forgetful or did you mean this post? It's not a patch, just the original version of premake I was using. The version you can download from the homepage is not the most current stable version and the most current one from bitbucket is newer than the version I was using. If you check the differences from this version to the one I've customized, you can see what I have changed.

It's a patch for the c++ sourcecode and isn't related to premake. Btw: I'll be on holiday the next three weeks starting next tuesday, so I won't be available in this time.

I've attached a patch which fixes errors when compiling atlas on osx with the version of wxwidgets provided by macports. Some functions don't yet support std::wstring as parameters in this version. I can compile now, but I can't link because a 64bit version of wxwidgets is missing. It looks like we'll have to add support for wxwidgets 2.9 for getting 64bit support. Simply setting arch=x86 in premake4.lua as a workaround doesn't work either because a lot of dependencies do their own architecture detection. atlas_patch.txt

The current stable version of wxwidgets doesn't support 64 bit on the Mac according to this document: http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard It should work with 2.9, but that's not stable yet and I couldn't compile atlas with the version provided by Macports.

I know this one. There are two function calls where the wxwidgets version coming with macports doesn't support std:wstring as parameter. If you put .c_str() after the parameter, it works and compiles. The other problem is that there's no 64bit version of wxwidgets available from macports. I've tried using homebrew, but I currently can't even get it to install any packages . I didn't make a patch yet because I'm not sure if using MacPorts is the right approach because of the missing 64bit version of wxwidgets.

Pets are AI killers. In Arma2 a rabbit or a chicken can cause your convoy of heavily armoured vehicles to stop (even after years of patching). No matter how urgent it is to move, your soldiers would even give their lives to save the poor chicken that could possibly run in front of their tank.

Have you installed the "build-essential" package?

Thank you for the feedback and the changes! There's no testgen project anymore. I'm invoking cxxtestgen from prebuild-commands and/or customized code for creating the projectfiles (look in premake4/src/actions). EDIT: I've attached the "vanilla"-premake I was using (had to add .txt to be able to upload). You can check what I've changed by making filediffs if you would like to know the details (e.g. diff -uNB --strip-trailing-cr file_original file_new). EDIT2: Also look at the know-issues, especially number one in this post. premake-stable-fc0374a03b17.tar.bz2.txt

@Chakakhan I had errors with OpenGl initalization too, no matter if using premake3 or premake4. The solution was updating my ati graphics driver. @janwas I've looked at the atlas problems. The version of wxwidgets coming with macports doesn't support std:wstring for some functions. Changing two lines of code makes it compile, but linking still fails. The problem is that there is no 64bit version of wxwidgets provided by macports. I'm still looking for appropriate solutions... Thank you for the hint about watching a topic. I already know about that feature, but it suddenly stops working from time to time. I don't know why this happens and haven't yet tried figuring it out.

Thank you, that's good news . I'll try to look at the forums more regularly in the next weeks so I can try to help if there are questions or problems. I've tested with deleting the cache and can confirm that it(still) works. The console doesn't wrap around, it's all on one line (see screenshot)... but that's just cosmetics. Hopefully I'll have some time next week to work on the problems with compiling atlas on OSX. Maybe It's just a small thing.