eyecreate Posted July 11, 2009 Report Share Posted July 11, 2009 I'm not sure if you have the makefile set to compile every arch when you compile, but I'm getting errors about compiling IA32 when IA32 is not set. This is making the build fail. ==== Building Collada ==== make[1]: `../../../binaries/system/libwxJS_dbg.a' is up to date. ==== Building test_gen ==== precompiled.cpp ia32.cpp In file included from ../../../source/lib/sysdep/arch/ia32/ia32.cpp:24: ../../../source/lib/sysdep/arch/ia32/ia32.h:26:3: error: #error "including ia32.h without ARCH_IA32=1" ==== Building AtlasUI ==== make[1]: *** [obj/lowlevel_Debug/ia32.o] Error 1 In file included from ../../../libraries/fcollada/include/FUtils/FUString.h:583, from ../../../libraries/fcollada/include/FUtils/FUtils.h:120, from ../../../libraries/fcollada/include/FCollada.h:49, from ../../../source/collada/precompiled.h:34, from ../../../source/collada/precompiled.cpp:18: ../../../libraries/fcollada/include/FUtils/FUStringBuilder.h:139: error: ‘void FUStringBuilderT<Char>::append(long unsigned int)’ cannot be overloaded ../../../libraries/fcollada/include/FUtils/FUStringBuilder.h:122: error: with ‘void FUStringBuilderT<Char>::append(uint64)’ make: *** [lowlevel] Error 2 make: *** Waiting for unfinished jobs.... Linking AtlasUI /usr/bin/ld: ../../../binaries/system/libAtlasObject_dbg.a(AtlasObjectXML.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC../../../binaries/system/libAtlasObject_dbg.a: could not read symbols: Bad valuecollect2: ld returned 1 exit statusmake[1]: *** [../../../binaries/system/libAtlasUI_dbg.so] Error 1make: *** [AtlasUI] Error 2make[1]: *** [obj/Collada_Debug/precompiled.h.gch] Error 1make: *** [Collada] Error 2 Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 11, 2009 Report Share Posted July 11, 2009 Hmm, I think we've only really tested it with 32-bit Linux. (I don't have easy access to a 64-bit machine to test it on.)For the ia32 error, it looks like it's possibly detecting the architecture incorrectly - if you modify build/premake/premake.lua line 15 to say 'arch = "amd64"' then maybe it'll work better, or maybe it'll just fail differently.The fcollada errors look like the external library isn't 64-bit compatible (it assumes long unsigned int != uint64) - perhaps that could be solved by simply commenting out line 139 in FUStringBuilder.h, though I don't know whether that'll break anything else.The "recompile with -fPIC" error sounds easy to solve - I've made some changes so if you run 'svn up' and 'update-workspaces' then it should be better (hopefully).An alternative is to just do a 32-bit build - I'm not familiar with how this works, but it might just involve editing premake.lua around line 140 to add "-m32" into the list of buildoptions (and making sure you have 32-bit versions of all external libraries). Quote Link to comment Share on other sites More sharing options...
janwas Posted July 11, 2009 Report Share Posted July 11, 2009 hm, the intent is to exclude ia32.cpp from 64-bit builds. Since it remains included, Philip is right about the root cause of the problem. Our premake script checks a HOSTTYPE environment variable - is that not set on your system or doesn't it equal x86_64?Unfortunately I don't know about GCC compiler switches for 32 vs. 64-bit, but at least the ia32.cpp problem is something that we'll easily be able to fix or work around. Quote Link to comment Share on other sites More sharing options...
eyecreate Posted July 12, 2009 Author Report Share Posted July 12, 2009 forcing arch=amd64 makes most of it compile fine after "svn up". My HOSTTYPE return "x86_64" like expected, which makes me wonder why it wouldn't see it. The only problem left is a new error that popped up.amd64_asm.asm ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:14: error: elf output format does not support 64-bit code ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:22: error: invalid operands in non-64-bit mode ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:23: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:23: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:24: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:24: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:26: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:26: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:27: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:28: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:28: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:29: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:29: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:39: error: invalid operands in non-64-bit mode ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:40: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:40: error: invalid effective address ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:42: error: invalid operands in non-64-bit mode ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:48: error: impossible combination of address sizes ../../../source/lib/sysdep/arch/amd64/amd64_asm.asm:48: error: invalid effective address make[1]: *** [obj/lowlevel_Debug/amd64_asm.o] Error 1 make: *** [lowlevel] Error 2 make: *** Waiting for unfinished jobs.... ..but it got down to linking the engine now. Quote Link to comment Share on other sites More sharing options...
janwas Posted July 12, 2009 Report Share Posted July 12, 2009 Good to hear that the ia32 problem is gone after forcing arch=amd64.My HOSTTYPE return "x86_64" like expected, which makes me wonder why it wouldn't see it.Yes indeed, that's strange.Did you run the same update-workspaces script initially and after changing the premake script to force arch=amd64? It'd be great if you could add some error("text") statements to the various branches of the if/else statements in premake.lua:20 to understand if it's getting there at all and whether OS == "windows" or HOSTTYPE != x86_64 (hopefully your environment variable doesn't have it in quotes).The only problem left is a new error that popped up.First of all, can you please ensure you have NASM >= 0.99.0? Running nasm -v will indicate the version, and nasm -hf indicates what formats are supported, which should hopefully include elf64.We apparently need to pass -f elf64 instead of -f elf to NASM for 64-bit builds. This is done by premake in build/premake/src/Src/gnu_cpp.c:520 . As a quick fix, you could just change elf to elf64, but to properly support 32 and 64 bit builds we'd need to upgrade to premake 4.1 (see http://industriousone.com/platforms-0). Would you be interested in such an undertaking? Quote Link to comment Share on other sites More sharing options...
olsner Posted July 12, 2009 Report Share Posted July 12, 2009 Apparently, HOSTTYPE is not exported by default (so premake sees the variable as undefined). I've added a hack in update-workspaces.sh that should forward the proper value to premake. I also added some code to send the proper elf64 format to nasm conditionally, so the assembly stuff should work out of the box on 64-bit linux now.About the fcollada compile errors, a work-around that worked for me (I'm also on 64-bit linux) was to just remove the #else of that #ifdef WIN32 - I seems visual c++ thinks 'int' is a different type than both int32 and int64. I went ahead and checked that change in, so let's just hope it didn't break 32-bit linux and mac os Quote Link to comment Share on other sites More sharing options...
eyecreate Posted July 12, 2009 Author Report Share Posted July 12, 2009 (edited) I'm almost there. I now get a binary for pyrogenesis_dbg, but it seg faults. it's probably because of this error, which is the only one I can find left in the build log.==== Building test ==== precompiled.cpp In file included from ../../../libraries/cxxtest/include/cxxtest/StdValueTraits.h:10, from ../../../source/lib/self_test.h:189, from ../../../source/pch/test/precompiled.h:24, from ../../../source/pch/test/precompiled.cpp:25: ../../../libraries/cxxtest/include/cxxtest/ValueTraits.h:281: error: redefinition of ‘class CxxTest::ValueTraits<long unsigned int>’ ../../../libraries/cxxtest/include/cxxtest/ValueTraits.h:266: error: previous definition of ‘class CxxTest::ValueTraits<long unsigned int>’coldlg.cpp treeid.cpp Linking pyrogenesis menu.cpp menuitem.cpp make[1]: *** [obj/test_Debug/precompiled.h.gch] Error 1 make: *** [test] Error 2 make: *** Waiting for unfinished jobs.... EDIT: i forgot to do a backtrace. Here is the backtrace on the binary I got.This GDB was configured as "x86_64-linux-gnu"... (gdb) run Starting program: /home/eyecreate/0ad/binaries/system/pyrogenesis_dbg [Thread debugging using libthread_db enabled] [New Thread 0x7fabe7915740 (LWP 14533)] Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x7fabe7915740 (LWP 14533)] 0x00000000008b42b3 in amd64_CAS () (gdb) bt#0 0x00000000008b42b3 in amd64_CAS ()#1 0x00000000008b4237 in cpu_CAS (location=0xc667c0, expected=0, newValue=1) at ../../../source/lib/sysdep/arch/amd64/amd64.cpp:63#2 0x00000000008bbdb6 in ModuleShouldInitialize (pInitState=0xc667c0) at ../../../source/lib/module_init.cpp:44#3 0x000000000089c5d1 in h_mgr_init () at ../../../source/lib/res/h_mgr.cpp:806#4 0x000000000065a59c in Init (args=@0x7fffefa58bd0, flags=0) at ../../../source/ps/GameSetup/GameSetup.cpp:875#5 0x00000000005b60e9 in RunGameOrAtlas (argc=1, argv=0x7fffefa58d18) at ../../../source/main.cpp:398#6 0x00000000005b6184 in main (argc=1, argv=0x7fffefa58d18) at ../../../source/main.cpp:414 Edited July 12, 2009 by eyecreate Quote Link to comment Share on other sites More sharing options...
janwas Posted July 12, 2009 Report Share Posted July 12, 2009 (edited) I've added a hack in update-workspaces.sh that should forward the proper value to premake. I also added some code to send the proper elf64 format to nasm conditionally, so the assembly stuff should work out of the box on 64-bit linux now.Great, thanks very much! Just in case someone runs into the same problem: my TortoiseSVN reported a checksum mismatch in build/premake and build/workspaces. I'm not sure as to the cause (possibly corruption of my local disk), but it can be fixed by deleting those directories and restoring them via SVN update.it's probably because of this error, which is the only one I can find left in the build log.hm, that looks fairly harmless (probably similar to the FCollada problem about int/long int being distinct types or not). Either way, the self-test is independent of the main executable.Thanks for doing a backtrace! Since the same asm code works on Win64 with the exception of register renaming to match the platform's convention, I'd suspect that is where the problem is. It looks like our idea of the registers is correct (c.f. http://en.wikipedia.org/wiki/X86_calling_c...ABI_convention).Could you please add an %error statement to the %else block in source\lib\sysdep\arch\amd64\amd64_abi.inc and rebuild? This will verify that we're using the right set of registers - if not, OS_LINUX isn't being defined on the NASM command line. Edited July 12, 2009 by janwas Quote Link to comment Share on other sites More sharing options...
LinuxDonald Posted July 13, 2009 Report Share Posted July 13, 2009 I have compiled the last svn version on my 64 bit sys and i become an segfault.Here is my gdb output:Starting program: /db/dev/oad/binaries/system/pyrogenesis_dbg [Thread debugging using libthread_db enabled]Program received signal SIGSEGV, Segmentation fault.0x00000000008ad4a3 in amd64_CAS ()(gdb) bt#0 0x00000000008ad4a3 in amd64_CAS ()#1 0x00000000008ad377 in cpu_CAS (location=0xd6a468, expected=0, newValue=1) at ../../../source/lib/sysdep/arch/amd64/amd64.cpp:63#2 0x00000000008b59e2 in ModuleShouldInitialize (pInitState=0xd6a468) at ../../../source/lib/module_init.cpp:44#3 0x0000000000899989 in h_mgr_init () at ../../../source/lib/res/h_mgr.cpp:806#4 0x0000000000651238 in Init (args=@0x7fffffffe0d0, flags=0) at ../../../source/ps/GameSetup/GameSetup.cpp:875#5 0x00000000005a3ec7 in RunGameOrAtlas (argc=1, argv=0x7fffffffe228) at ../../../source/main.cpp:398#6 0x00000000005a3f5c in main (argc=1, argv=0x7fffffffe228) at ../../../source/main.cpp:414(gdb) Quote Link to comment Share on other sites More sharing options...
eyecreate Posted July 13, 2009 Author Report Share Posted July 13, 2009 The error statement is being found:amd64_abi.inc:7: %error: make[1]: *** [obj/lowlevel_Debug/amd64_asm.o] Error 1 make: *** [lowlevel] Error 2 Quote Link to comment Share on other sites More sharing options...
janwas Posted July 13, 2009 Report Share Posted July 13, 2009 I have compiled the last svn version on my 64 bit sys and i become an segfault.Here is my gdb output:Thanks for reporting the problem, it appears to be the same as above.The error statement is being found:Excellent, it looks like we've found the culprit, then. You can work around it for now by commenting out everything but the contents of the %ifdef OS_LINUX block in amd64_abi.inc (a proper fix follows).@olsner: could you please add "-dOS_LINUX=1 "; to Premake's GCC command line? (amd64_abi.inc relies on that being set, else it uses Win64's calling convention, thus causing CAS to misinterpret its arguments and segfault). Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 13, 2009 Report Share Posted July 13, 2009 I also have some problems with building on x86_64.1) I see several warnings of type"warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’"You know this is a severe bug for 64-bit UNIX-like systems as sizeof(int) = 4 while sizeof(long int) = 8 and this types' mixing causes memory overflow and segfaults. All this warnings should be fixed. For more info see here.2) Compilation breaks with this messages:==== Building pyrogenesis ==== main.cpp Linking pyrogenesis /usr/bin/ld: Dwarf Error: Offset (2628) greater than or equal to .debug_str size (219). ../../../binaries/system/liblowlevel_dbg.a(amd64.o): In function `cpu_AtomicAdd(long volatile*, long)': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/amd64/amd64.cpp:58: undefined reference to `amd64_AtomicAdd' ../../../binaries/system/liblowlevel_dbg.a(amd64.o): In function `cpu_CAS(unsigned long volatile*, unsigned long, unsigned long)': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/amd64/amd64.cpp:63: undefined reference to `amd64_CAS' ../../../binaries/system/liblowlevel_dbg.a(x86_x64.o): In function `cpuid_impl': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/x86_x64/x86_x64.cpp:58: undefined reference to `amd64_asm_cpuid' collect2: ld returned 1 exit status3) When I did "svn co" I've noticed a lot of windows exe, dll and pdb files. Is it possible to remove them from svn to not download them on non-windows OS? Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 13, 2009 Report Share Posted July 13, 2009 1) I see several warnings of type"warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’"Could you upload the list of those warnings to somewhere? They do seem dangerous, so it'd be good to fix them.3) When I did "svn co" I've noticed a lot of windows exe, dll and pdb files. Is it possible to remove them from svn to not download them on non-windows OS?It would be possible, but then Windows users would be unable to compile or play the game without a load of pain recompiling those libraries, unless we had two separate SVN URLs (one for Windows users, one for Linux/OSX users) but that seems a bit ugly and confusing, so it'd be easier to stick with what it does already, unless there are good reasons to change... Why do you want to not download those files? Quote Link to comment Share on other sites More sharing options...
eyecreate Posted July 13, 2009 Author Report Share Posted July 13, 2009 alright! it doesn't seg fault on start. what isn't good is that the game asks to attach a debugger when loading a game(I tried single player). A thirty line backtrace follows.Attaching to process 9802 (gdb)bt#0 0x00007f41cb7e5d21 in nanosleep () from /lib/libc.so.6#1 0x00007f41cb7e5b47 in __sleep (seconds=<value optimized out>) at ../sysdeps/unix/sysv/linux/sleep.c:138#2 0x00000000008bb015 in udbg_launch_debugger () at ../../../source/lib/sysdep/os/unix/udbg.cpp:85#3 0x00000000008bad61 in sys_display_error (text=0x7f41b927a000, flags=6) at ../../../source/lib/sysdep/os/unix/unix.cpp:66#4 0x0000000000888785 in CallDisplayError (text=0x7f41b927a000, flags=6) at ../../../source/lib/debug.cpp:365#5 0x0000000000888faf in debug_DisplayError (description=0x4c5c410, flags=6, context=0x0, lastFuncToSkip=0x90b1f0 "debug_OnAssertionFailure", pathname=0x912038 "../../../source/lib/allocators/headerless.cpp", line=333, func=0x912451 "Validate", suppress=0xc6d162 "") at ../../../source/lib/debug.cpp:440#6 0x0000000000889096 in debug_OnAssertionFailure (expr=0x912128 "((m_bitmap & Bit<u32>(i)) == 0) == m_rangeLists[i].IsEmpty()", suppress=0xc6d162 "", file=0x912038 "../../../source/lib/allocators/headerless.cpp", line=333, func=0x912451 "Validate") at ../../../source/lib/debug.cpp:515#7 0x00000000008caab4 in SegregatedRangeLists::Validate (this=0x2a9c380, id=287215215) at ../../../source/lib/allocators/headerless.cpp:333#8 0x00000000008cb6d9 in HeaderlessAllocator::Impl::Validate (this=0x2a9c340) at ../../../source/lib/allocators/headerless.cpp:659#9 0x00000000008cb8c4 in HeaderlessAllocator::Impl::Deallocate (this=0x2a9c340, p=0x7f41c4c77000 "", size=2097152) at ../../../source/lib/allocators/headerless.cpp:652#10 0x00000000008c9fe1 in HeaderlessAllocator::Deallocate (this=0x2a9c170, p=0x7f41c4c77000, size=2097152) at ../../../source/lib/allocators/headerless.cpp:752#11 0x00000000008c5596 in Allocator::Deallocate (this=0x2a9c170, mem=0x7f41c4c77000 "", size=1955683) at ../../../source/lib/file/vfs/file_cache.cpp:120#12 0x00000000008c1bee in FileCacheDeleter::operator() (this=0x362fae8, mem=0x7f41c4c77000 "") at ../../../source/lib/file/vfs/file_cache.cpp:136#13 0x00000000008c5953 in boost::detail::sp_counted_impl_pd<unsigned char*, FileCacheDeleter>::dispose (this=0x362fad0) at /usr/include/boost/detail/sp_counted_impl.hpp:144#14 0x00000000005b631c in boost::detail::sp_counted_base::release (this=0x362fad0) at /usr/include/boost/detail/sp_counted_base_gcc_x86.hpp:145#15 0x00000000005b634c in ~shared_count (this=0x7fffd73fedb8) at /usr/include/boost/detail/shared_count.hpp:204#16 0x000000000060fa57 in ~shared_ptr (this=0x7fffd73fedb0) at /usr/include/boost/shared_ptr.hpp:148#17 0x00000000008c58f7 in FileCache::Impl::Reserve (this=0x2a9c2e0, size=231378) at ../../../source/lib/file/vfs/file_cache.cpp:180#18 0x00000000008c1c27 in FileCache::Reserve (this=0x2a9c240, size=231378) at ../../../source/lib/file/vfs/file_cache.cpp:228#19 0x000000000089b98c in VFS::LoadFile (this=0x2a9c230, pathname=@0x7fffd73ff160, fileContents=@0x7fffd73fefc0, size=@0x7fffd73fefd0) at ../../../source/lib/file/vfs/vfs.cpp:124#20 0x0000000000632ba3 in CVFSFile::Load (this=0x7fffd73fefc0, filename=@0x7fffd73ff160) at ../../../source/ps/Filesystem.cpp:57#21 0x0000000000667bf5 in CXeromyces::Load (this=0x4c64730, filename=@0x7fffd73ff160) at ../../../source/ps/XML/Xeromyces.cpp:151#22 0x000000000075a13a in CXMLReader::Init (this=0x4c64730, xml_filename=@0x384afb8) at ../../../source/graphics/MapReader.cpp:315#23 0x000000000075f546 in CXMLReader (this=0x4c64730, xml_filename=@0x384afb8, mapReader=@0x384ae90) at ../../../source/graphics/MapReader.cpp:266#24 0x000000000075a4b1 in CMapReader::ReadXML (this=0x384ae90) at ../../../source/graphics/MapReader.cpp:1030#25 0x00000000007530ba in MemFunThunk<CMapReader> (param=0x384b070) at ../../../source/ps/LoaderThunks.h:57#26 0x0000000000622d90 in LDR_ProgressiveLoad (time_budget=0.01, description=0x7fffd73ff310, max_chars=100,#27 0x00000000005b56bf in ProgressiveLoad () at ../../../source/main.cpp:150#28 0x00000000005b5aa7 in Frame () at ../../../source/main.cpp:247#29 0x00000000005b60f5 in RunGameOrAtlas (argc=1, argv=0x7fffd73ff6e8) at ../../../source/main.cpp:401#30 0x00000000005b6184 in main (argc=1, argv=0x7fffd73ff6e8) at ../../../source/main.cpp:414 Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 13, 2009 Report Share Posted July 13, 2009 Could you upload the list of those warnings to somewhere? They do seem dangerous, so it'd be good to fix them.I'll try to create this list...It would be possible, but then Windows users would be unable to compile or play the game without a load of pain recompiling those libraries, unless we had two separate SVN URLs (one for Windows users, one for Linux/OSX users) but that seems a bit ugly and confusing, so it'd be easier to stick with what it does already, unless there are good reasons to change... Why do you want to not download those files? I do not want to download those files because they are rather large and waste of download time, traffic and disk space. It would be great to have svn for source code only and separate tar-balls for binary data and windows dependencies.Windows binaries weight ~60 Mb, and sources of the libraries that (most of them) usually installed systemwide on all modern linux systems weight ~160 Mb. These are too large pieces of unneeded data, and they make difficult to package binary linux packages (rpm, deb) as there also should be source packages. I do not think any linux distribution can provide source package that contains MSVC dlls and they won't provide binary packages without source packages (GPL violation).And there is another 'little' problem - your suggestion to use SpiderMonkey 1.6. On all modern linux distributions it is impossible as they all provide newer versions of js package - usually 1.7 or even 1.8 rc1. And, more over, they install header files for the library in different directories so your implicit suggestion to include <js/jsapi.h> is absolutely incorrect. For example on mandriva linux this header is located in /usr/include/js-1.7.0 dir and on fedora it is located directly in /usr/include. To resolve this difference you should use pkgconfig utility that would provide you correct -I compiler options for header files and libraries. Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 13, 2009 Report Share Posted July 13, 2009 The list of warnings:../../../source/ps/Util.cpp: In function ‘void WriteSystemInfo()’:../../../source/ps/Util.cpp:96: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’../../../source/ps/Util.cpp:96: warning: format ‘%d’ expects type ‘int’, but argument 6 has type ‘size_t’../../../source/ps/Util.cpp:96: warning: format ‘%d’ expects type ‘int’, but argument 7 has type ‘size_t’../../../source/ps/Util.cpp:109: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’../../../source/ps/Util.cpp:109: warning: format ‘%u’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’../../../source/scripting/ScriptGlue.cpp: In function ‘void InitJsTimers()’:../../../source/scripting/ScriptGlue.cpp:648: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’../../../source/renderer/Renderer.cpp: In member function ‘virtual CStr8 CRendererStatsTable::GetCellText(size_t, size_t)’:../../../source/renderer/Renderer.cpp:152: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:152: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:158: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:158: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:164: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:164: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:170: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:170: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:176: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/Renderer.cpp:176: warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’../../../source/renderer/WaterManager.cpp: In member function ‘int WaterManager::LoadWaterTextures()’:../../../source/renderer/WaterManager.cpp:114: warning: format ‘%02d’ expects type ‘int’, but argument 5 has type ‘size_t’../../../source/renderer/WaterManager.cpp:114: warning: format ‘%02d’ expects type ‘int’, but argument 5 has type ‘size_t’../../../source/renderer/WaterManager.cpp:131: warning: format ‘%02d’ expects type ‘int’, but argument 5 has type ‘size_t’../../../source/renderer/WaterManager.cpp:131: warning: format ‘%02d’ expects type ‘int’, but argument 5 has type ‘size_t’../../../source/tools/atlas/GameInterface/MessagePasserImpl.cpp: In constructor ‘MessagePasserImpl::MessagePasserImpl()’:../../../source/tools/atlas/GameInterface/MessagePasserImpl.cpp:37: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’../../../source/lib/sysdep/os/linux/ldbg.cpp: In function ‘LibError debug_resolve_symbol_dladdr(void*, char*, char*, int*)’:../../../source/lib/sysdep/os/linux/ldbg.cpp:303: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’../../../source/lib/sysdep/os/linux/ldbg.cpp:303: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 4 has type ‘size_t’And there are some sizeofs:sizeof(int)=4sizeof(long)=8sizeof(size_t)=8sizeof(*int)=8 (pointer to int). Quote Link to comment Share on other sites More sharing options...
olsner Posted July 13, 2009 Report Share Posted July 13, 2009 @olsner: could you please add "-dOS_LINUX=1 "; to Premake's GCC command line? (amd64_abi.inc relies on that being set, else it uses Win64's calling convention, thus causing CAS to misinterpret its arguments and segfault).D'oh. Should be fixed now. Quote Link to comment Share on other sites More sharing options...
olsner Posted July 13, 2009 Report Share Posted July 13, 2009 About that assertion, the game seems to launch after just suppressing it. (But of course it should also be fixed)About the cxxtest error:In file included from ../../../libraries/cxxtest/include/cxxtest/StdValueTraits.h:10, from ../../../source/lib/self_test.h:189, from ../../../source/pch/test/precompiled.h:24, from ../../../source/pch/test/precompiled.cpp:25: ../../../libraries/cxxtest/include/cxxtest/ValueTraits.h:281: error: redefinition of ‘class CxxTest::ValueTraits<long unsigned int>’ ../../../libraries/cxxtest/include/cxxtest/ValueTraits.h:266: error: previous definition of ‘class CxxTest::ValueTraits<long unsigned int>’I have a fix for this locally, but as usual I don't really know if it will break Windows Index: include/cxxtest/ValueTraits.h===================================================================--- include/cxxtest/ValueTraits.h (revision 6954)+++ include/cxxtest/ValueTraits.h (working copy)@@ -276,10 +276,8 @@ CXXTEST_COPY_TRAITS( const unsigned char, const unsigned long int ); CXXTEST_COPY_CONST_TRAITS( signed int );- //CXXTEST_COPY_CONST_TRAITS( unsigned int );-#ifndef __APPLE__ // avoid redefinition errors on mac- CXXTEST_COPY_TRAITS( size_t, const unsigned int ); // avoid /Wp64 warnings in MSVC-#endif+ CXXTEST_COPY_CONST_TRAITS( unsigned int );+ CXXTEST_COPY_CONST_TRAITS( signed short int ); CXXTEST_COPY_CONST_TRAITS( unsigned short int ); CXXTEST_COPY_CONST_TRAITS( unsigned char ); Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 14, 2009 Report Share Posted July 14, 2009 BTW, lowlevel.make file contains two different rules for precompiled.h.gch file:$(OBJDIR)/precompiled.h.gch: ../../../source/lib/precompiled.cpp -@$(CMD_MKOBJDIR) @echo $(notdir $<) @$(CXX) $(CXXFLAGS) -MF $(OBJDIR)/precompiled.d -o $@ -c -x c++-header $<at lines 197-200 and$(OBJDIR)/precompiled.h.gch: ../../../source/pch/lowlevel/precompiled.cpp -@$(CMD_MKOBJDIR) @echo $(notdir $<) @$(CXX) $(CXXFLAGS) -MF $(OBJDIR)/precompiled.d -o $@ -c -x c++-header $<at lines 633-636. It it normal? And which of the two is correct? Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 14, 2009 Report Share Posted July 14, 2009 I do not want to download those files because they are rather large and waste of download time, traffic and disk space. It would be great to have svn for source code only and separate tar-balls for binary data and windows dependencies.Windows binaries weight ~60 Mb, and sources of the libraries that (most of them) usually installed systemwide on all modern linux systems weight ~160 Mb. These are too large pieces of unneeded data, and they make difficult to package binary linux packages (rpm, deb) as there also should be source packages. I do not think any linux distribution can provide source package that contains MSVC dlls and they won't provide binary packages without source packages (GPL violation).Hmm, I suppose the way I see it is that SVN is for development and should be optimised for that. For distribution, we'd probably want a system that extracts all the Windows binaries and data files and makes a nice installer package, and also extracts the source code and build system files to make something that can be compiled and packaged on Linux, and also extracts the data files you need to run it on Linux so they can be packaged separately. At the moment, I think we're very much in the development stage and it'd be premature to set up a packaging/distribution system.And there is another 'little' problem - your suggestion to use SpiderMonkey 1.6. On all modern linux distributions it is impossible as they all provide newer versions of js package - usually 1.7 or even 1.8 rc1.Yeah, it's a bit of a pain. The problem is that different versions of SpiderMonkey implement different versions of JS, and we want a consistent language to avoid problems where someone writes a script that works fine on their computer but fails (or works differently) on someone else's, so it needs to be a specific version. Also, several years ago some distributions only provided non-threadsafe SpiderMonkey builds, which won't work for our game - I don't know if that's still the case or if they're all threadsafe now. Also, at some point in the future we might need to tweak the SpiderMonkey code or compiler settings so that it gives precisely reproducible results between platforms, since our multiplayer system relies on all simulations being identical.So I think we do need a specific custom version, and can't rely on the system-provided one. (But installing the custom version it in /usr/{lib,include} seems a terrible idea - it ought to be going in a project-specific directory somewhere...) Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 14, 2009 Report Share Posted July 14, 2009 BTW, lowlevel.make file contains two different rules for precompiled.h.gch fileThat's a bug, but as far as I'm aware it has no effect, so I've never cared enough to try fixing it . source/pch/lowlevel/precompiled.cpp is the correct one; I believe the other file exists because the 'lowlevel' directory is shared with some other projects and so it has a source/lowlevel/precompiled.cpp for use when the 'pch' directory isn't present. For 0 A.D. the easy fix is to just delete source/lowlevel/precompiled.cpp, but I think janwas still wants it there, so the less easy fix is to modify build/premake/premake.lua to somehow exclude that file from the list that will get built. Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 14, 2009 Report Share Posted July 14, 2009 (edited) 2) Compilation breaks with this messages:==== Building pyrogenesis ==== main.cpp Linking pyrogenesis /usr/bin/ld: Dwarf Error: Offset (2628) greater than or equal to .debug_str size (219). ../../../binaries/system/liblowlevel_dbg.a(amd64.o): In function `cpu_AtomicAdd(long volatile*, long)': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/amd64/amd64.cpp:58: undefined reference to `amd64_AtomicAdd' ../../../binaries/system/liblowlevel_dbg.a(amd64.o): In function `cpu_CAS(unsigned long volatile*, unsigned long, unsigned long)': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/amd64/amd64.cpp:63: undefined reference to `amd64_CAS' ../../../binaries/system/liblowlevel_dbg.a(x86_x64.o): In function `cpuid_impl': /home/olelukoie/rpmbuild/BUILD/0ad/0ad/build/workspaces/gcc/../../../source/lib/sysdep/arch/x86_x64/x86_x64.cpp:58: undefined reference to `amd64_asm_cpuid' collect2: ld returned 1 exit statusIt's very strange, but I've managed to solve this problem only by replacing 'nasm' with 'yasm' in lowlevel.make. Seems like a bug in nasm (2.06). When I try to do 'objdump -t amd64_asm.o' after nasm I see the message 'file format not recognized'...But now the next problem with wxgtk:../../../source/tools/atlas/AtlasScript/ScriptInterface.cpp:265: error: no matching function for call to ‘wxMBConvUTF16LE::cWC2MB(const wxChar*, size_t, size_t*)’/usr/include/wx-2.8/wx/strconv.h:89: note: candidates are: const wxCharBuffer wxMBConv::cWC2MB(const wchar_t*) const/usr/include/wx-2.8/wx/strconv.h:106: note: const wxCharBuffer wxMBConv::cWC2MB(const wchar_t*, size_t, size_t*) constSeems like it needs explicit data conversion from wxChar to wchar_t... And the same error in atlas/AtlasScript/ScriptInterface.cpp:749. Edited July 14, 2009 by olelukoie Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 14, 2009 Report Share Posted July 14, 2009 Seems like it needs explicit data conversion from wxChar to wchar_t...Are you using a Unicode build of wxWidgets? e.g. if you run "wx-config --cppflags" it should hopefully say something like "-I/usr/lib/wx/include/gtk2-unicode-release-2.8 ...".If so, wxChar really ought to be equal to wchar_t, and I can't imagine why it would fail. (But if it's not Unicode then wxChar is char, and ideally you should get a Unicode version instead. It probably would be possible to make Atlas compile with non-Unicode wx, but that wouldn't be a very nice solution compared to just using Unicode.) Quote Link to comment Share on other sites More sharing options...
Guest olelukoie Posted July 14, 2009 Report Share Posted July 14, 2009 Are you using a Unicode build of wxWidgets? e.g. if you run "wx-config --cppflags" it should hopefully say something like "-I/usr/lib/wx/include/gtk2-unicode-release-2.8 ...".See the difference:[olelukoie@olelukoie-linux gcc]$ wx-config --cppflags-I/usr/lib64/wx/include/ -I/usr/lib64/wx/include/gtk2-ansi-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__and[olelukoie@olelukoie-linux gcc]$ wx-config --unicode=yes --cppflags-I/usr/lib64/wx/include/ -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ You missed --unicode=yes option... Quote Link to comment Share on other sites More sharing options...
Ykkrosh Posted July 14, 2009 Report Share Posted July 14, 2009 Ah, right - it defaults to the Unicode version on mine so I never noticed that flag. I've modified build/premake/extern_libs.lua to do --unicode=yes - if you run update-workspaces again then hopefully it'll work it a bit better Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.