Jump to content

Echelon9

Donator
  • Posts

    87
  • Joined

  • Last visited

Posts posted by Echelon9

  1. From a quick playtest here no issues apparent. Running through single player skirmish, setting up a hosted game and opening Atlas Editor.

    $ uname -msrDarwin 13.4.0 x86_64$ $ otool -L 0ad.app/Contents/MacOS/pyrogenesis 0ad.app/Contents/MacOS/pyrogenesis:	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)	/System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0)	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)	/System/Library/Frameworks/ForceFeedback.framework/Versions/A/ForceFeedback (compatibility version 1.0.0, current version 1.0.2)	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.8.0)	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0)	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 2577.0.0)	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0)	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
  2. The compile error is:

    Undefined symbols for architecture x86_64:  "std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> >::empty() const", referenced from:      CParamNode::ApplyLayer(XMBFile const&, XMBElement const&, wchar_t const*) in libsimulation2_dbg.a(ParamNode.o)ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)
  3. Hi ben,

    Thanks for the most recent changes to SVN which assist building on Mac. With r15726, and a clean build I was able to follow the current instructions on Trac under BuildInstructions / Mac / "1. Build the game for your personal use", with only one small patch required.

    Almost there. I think it's a libc++ issue with the pyrogensis use of those C++11 functions.

    Index: source/simulation2/system/ParamNode.cpp===================================================================--- source/simulation2/system/ParamNode.cpp	(revision 15726)+++ source/simulation2/system/ParamNode.cpp	(working copy)@@ -113,8 +113,8 @@ 				boost::algorithm::split(newTokens, value, boost::algorithm::is_space());  				// Delete empty tokens-				oldTokens.erase(std::remove_if(oldTokens.begin(), oldTokens.end(), std::mem_fun_ref(&std::wstring::empty)), oldTokens.end());-				newTokens.erase(std::remove_if(newTokens.begin(), newTokens.end(), std::mem_fun_ref(&std::wstring::empty)), newTokens.end());+				//oldTokens.erase(std::remove_if(oldTokens.begin(), oldTokens.end(), std::mem_fun_ref(&std::wstring::empty)), oldTokens.end());+				//newTokens.erase(std::remove_if(newTokens.begin(), newTokens.end(), std::mem_fun_ref(&std::wstring::empty)), newTokens.end());  				// Merge the two lists 				std::vector<std::wstring> tokens = oldTokens;
  4. I gave the current SVN version a go using the command line tools (Mavericks, no XCode installed) and I ran into a build problem for wxWidgets, a 'type_traits' error:

    <snip></snip>

    Perhaps there is a simple fix for this, but I might have missed that.

    Did you go about building the game as an App bundle (./build-osx-bundle.sh) or a loose binary (./build-osx-libs.sh followed by make)?

    See further here: http://trac.wildfiregames.com/wiki/BuildInstructions#OSX

  5. With wraitii's assistance on IRC, I was able to build an 0ad.app for the first time on OS X Mavericks 10.9. Wraitii and I will separately write up and settle the building steps for this platform.



    This pleasing development did allow me to test the UPnP-related double free patch (#2338) on the Mac platform.



    Happily to say, the latest patch permitted no crashes when running the UPnP setup routines affected by the double-free bug. My testing confirmed the UPnP Internet Gateway Device was successfully contacted and the port forward registered (run one).



    A second run which cached the location of the UPnP IGD also worked as expected without any crashes.



    So this is confirmation from at least one testing platform (OSX 10.9) that the latest patch attached here does fix the memory corruption bug.


    N.B this memory corruption will in fact affect each platform (Win, Linux, Mac) but it appears to only cause a hard crash for now on Mac.



    Subtler bugs may be being happening on other platforms and it would be good to get it fixed up promptly. I've seen reported on other platforms of memory issues in and around this function.


  6. Hmmm, I've got some weird news. I get the error you get, but only when trying on Xcode. If I run "build-osx-bundle", I get no such error. For some reason.

    Try removing the boost and gloox folder and running build-osx-bundle, which should call build-osx-libs to rebuild those, and see what happens.

    Hi -

    I tried as suggested and deleted the gloox/boost folders then re-ran ./build-osx-bundle.sh -j3. The error reported was:

    Undefined symbols for architecture x86_64:  "std::runtime_error::runtime_error(char const*)", referenced from:      (anonymous namespace)::UnixAssertHandler::assert(char const*, char const*, int, char const*) in libnvcore.a(Debug.cpp.o)ld: symbol(s) not found for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)

    I also tried the similar step of deleting gloox/boost and then running the ./build-osx-libs.sh script standalone. It reported the same error about missing symbols and use_facet() unfortunately.

    So sadly both tests didn't progress the work to create a working bundle or loose binary on Mac OS X 10.9.

  7. Edit: Hmmm, I got the same error you do, tried adding MishFTW's stuff back and still get it. This is weird.

    Good to know it's not my dev setup -- there's an intermediate required step here that is yet to be really nailed down in the clear description of Mac building steps.

    historic_bruno: I'll add a patch to the Trac ticket, but caveat that it's unable to have been reviewed so doesn't meet the normal standards I'd expect of myself.

    Update: Two alternative patches attached to the ticket.

  8. Okay, so I tried just omitting the need to link that function call into iconv by changing to this line in source/thirdparty/tinygettext/src/iconv.cpp:

    ...     // Try to convert the text.    size_t ret = static_cast<size_t>(-1);   // HACKY HACKY    if (ret == static_cast<size_t>(-1))    {...

    Unfortunately, while the compilation proceeded far past the previous error, it reported a subsequent error as so from source/ps/Filesystem.cpp when calling std::wstring GetWstringFromWpath(const fs::wpath& path):

    ==== Building pyrogenesis (release) ======== Building test (release) ====Linking pyrogenesisld: warning: directory not found for option '-L../../../libraries/source/cxxtest-4.3/lib'Linking testld: warning: directory not found for option '-L../../../libraries/source/cxxtest-4.3/lib'Undefined symbols for architecture x86_64:  "boost::filesystem::path_traits::convert(char const*, char const*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, std::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from:      GetWstringFromWpath(boost::filesystem::path const&) in libengine.a(Filesystem.o)  "boost::filesystem::path_traits::convert(wchar_t const*, wchar_t const*, std::string&, std::codecvt<wchar_t, char, __mbstate_t> const&)", referenced from:      CTextureManagerImpl::GetConverterSettings(boost::shared_ptr<CTexture> const&) in libgraphics.a(TextureManager.o)      GetAIsHelper::Callback(Path const&, CFileInfo const&, unsigned long) in libsimulation2.a(ICmpAIManager.o)  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find_last_of(char const*, unsigned long, unsigned long) const", referenced from:      boost::filesystem::path::m_parent_path_end() const in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::filename() const in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o)  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::find_first_of(char const*, unsigned long, unsigned long) const", referenced from:      (anonymous namespace)::root_directory_start(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long) in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::filename() const in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::m_path_iterator_increment(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o)  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::rfind(char, unsigned long) const", referenced from:      boost::filesystem::path::extension() const in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::stem() const in libboost_filesystem-mt.a(path.o)  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(char const*) const", referenced from:      boost::filesystem::path::begin() const in libboost_filesystem-mt.a(path.o)      boost::filesystem::path::m_path_iterator_decrement(boost::filesystem::path::iterator&) in libboost_filesystem-mt.a(path.o)  "std::__1::__basic_string_common<true>::__throw_length_error() const", referenced from:      boost::filesystem::path::path<char const*>(char const*, char const*) in libboost_filesystem-mt.a(path.o)  "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from:      boost::filesystem::path::imbue(std::__1::locale const&) in libboost_filesystem-mt.a(path.o)      __GLOBAL__I_a in libboost_filesystem-mt.a(path.o)  "std::__1::codecvt<wchar_t, char, __mbstate_t>::do_length(__mbstate_t&, char const*, char const*, unsigned long) const", referenced from:      vtable for boost::filesystem::detail::utf8_codecvt_facet in libboost_filesystem-mt.a(utf8_codecvt_facet.o)
  9. It appears the change to libraries/osx/iconv/include/iconv.h was either overwritten or not applied correctly, as following through your steps I was getting this error on running your modified build-osx-bundle.sh.

    $ ./build-osx-bundle.sh==== Building network (release) ======== Building mocks_real (release) ======== Building tinygettext (release) ======== Building lobby (release) ======== Building glooxwrapper (release) ======== Building simulation2 (release) ====iconv.cpp==== Building scriptinterface (release) ======== Building engine (release) ====../../../source/third_party/tinygettext/src/iconv.cpp:118:18: error: no matching function for call to 'libiconv'    size_t ret = tinygettext_iconv(cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft);                 ^~~~~~~~~~~~~~~~~../../../source/third_party/tinygettext/include/tinygettext/iconv.hpp:40:35: note: expanded from macro 'tinygettext_iconv'#  define tinygettext_iconv       iconv                                  ^~~~~../../../libraries/osx/iconv/include/iconv.h:81:15: note: expanded from macro 'iconv'#define iconv libiconv              ^~~~~~~~../../../libraries/osx/iconv/include/iconv.h:83:15: note: candidate function not viable: no known conversion from 'const char **' to 'char **' for 2nd argumentextern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);              ^../../../libraries/osx/iconv/include/iconv.h:81:15: note: expanded from macro 'iconv'#define iconv libiconv              ^==== Building graphics (release) ====1 error generated.make[1]: *** [obj/tinygettext_Release/iconv.o] Error 1make: *** [tinygettext] Error 2make: *** Waiting for unfinished jobs....

    When I open libraries/osx/iconv/include/iconv.h at line 83 it does show the included const.

    ...extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);...

    Perhaps your description of the step you took is not quite in the right order, or there was an intermediate rebuild somewhere?

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

    I can provide a patch for the UPnP memory corruption, I just can't verify it works on all cases until there's a reproducible means of building on Mac OS X so am keen to see wraitii's SVN commits. To note the memory corruption is not Mac specific, it's just be most demonstrably seen on that platform.

  11. Not me, I'm on Mavericks 10.9.3 using the below clang version and I get the use_facet() related build issue with the icu library. It's related to the stdlib in use, which for some reason isn't being correctly set from the build environment for that library.

    .../Applications/Xcode.app/Contents/Developer/usr/bin/make[1]: Making `all' in `icuinfo'   clang++	 ...  ../../../tools/icuinfo/icuinfo.cppclang++ -std=c++11  -arch x86_64 -fvisibility=hidden -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long  -Qunused-arguments -Wno-parentheses-equality -stdlib=libstdc++ -arch x86_64  -o icuinfo icuinfo.o -L../../lib -licutu -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -lpthread -lm   Undefined symbols for architecture x86_64:  "std::__1::locale::use_facet(std::__1::locale::id&) const", referenced from:      KnownIssues::print() in libicutu.a(udbgutil.ao)      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*) in libicutu.a(udbgutil.ao)      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in libicutu.a(udbgutil.ao)      std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char) in libicutu.a(udbgutil.ao)
    $ clang++ --versionApple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)Target: x86_64-apple-darwin13.2.0Thread model: posix

    To be clear, I had followed the instructions on the BuildInstructions page per:

    • A workaround may be to run the following commands in the terminal before building: export CFLAGS="-stdlib=libstdc++" LDFLAGS="-stdlib=libstdc++"
      export CC=clang CXX=clang++
    • Add toolset=clang to the Boost.Build (b2) flags in build-osx-libs.sh.
  12. I've updated ticket #2338 with my assessment of the cause for memory corruption at this location. I'd have provided a patch, but am having on-going issues building correctly on Mac 10.9.

    http://trac.wildfiregames.com/ticket/2338#comment:24

    The instructions document why a block of memory is free'd that was never allocated when a cached UPnP URL is utilised. With an accompanying reading of the provided miniupnpc API documentation for the function UPNP_GetValidIGD(), a patch should be pretty quick to write.

×
×
  • Create New...