Kompilacja VCMI na OS X 10.7 Lion

Cześć,

Postanowiłem spróbować skompilować projekt na OS X. Przeprowadziłem już pierwsze próby ale najwyraźniej skrypt configure nie znajduje u mnie zainstalowanego SDLa i Boosta.

Jednakże:

nooga$ sdl-config  --version
1.2.15
nooga$ ls /usr/local/include/SDL/
SDL.h		SDL_cdrom.h	SDL_error.h ....]
nooga$ sdl-config  --libs
-L/usr/local/lib -lSDLmain -lSDL -Wl,-framework,Cocoa

Boost w wersji 1.49.0 siedzi natomiast w /opt/local/

Nie za bardzo wiem jak naprowadzić build system na te liby - jeśli ktoś może pomóc to będę wdzięczny :slight_smile:

Już nie mogę się doczekać problemów, które spotkam po uruchomieniu make :stuck_out_tongue:

Po lekturze config.log wykumałem, że testy failują przez to, że applowskie gcc jest stare i nie rozumie -std=c++0x.

Zmiana kompilatora:

$ export CXX=clang++

Spowodowała poprawne wykrycie wszystkich libów i wygenerowanie makefile.

Niestety przy próbie wywołania make dostaję od razu:

nooga$ make
Making all in lib
clang++ -DPACKAGE_NAME=\"vcmi\" -DPACKAGE_TARNAME=\"vcmi\" -DPACKAGE_VERSION=\"0.89\" -DPACKAGE_STRING=\"vcmi\ 0.89\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"vcmi\" -DVERSION=\"0.89\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_BOOST=/\*\*/ -DHAVE_BOOST_SYSTEM=/\*\*/ -DHAVE_BOOST_FILESYSTEM=/\*\*/ -DHAVE_BOOST_THREAD=/\*\*/ -DHAVE_BOOST_IOSTREAMS=/\*\*/ -DHAVE_BOOST_PROGRAM_OPTIONS=/\*\*/ -DHAVE_LIBDL=1 -DHAVE_SDL_SDL_H=1 -DHAVE_SDL_SDL_MIXER_H=1 -DHAVE_SDL_SDL_IMAGE_H=1 -DHAVE_SDL_SDL_TTF_H=1 -DHAVE_LIBSDL=1 -DHAVE_LIBSDL_MIXER=1 -DHAVE_LIBSDL_IMAGE=1 -DHAVE_LIBSDL_TTF=1 -DHAVE_LIBAVFORMAT=1 -DHAVE_LIBSWSCALE=1 -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_BOOST_FILESYSTEM_HPP=1 -DHAVE_BOOST_ALGORITHM_STRING_HPP=1 -DHAVE_BOOST_ALGORITHM_STRING_REPLACE_HPP=1 -DHAVE_BOOST_FILESYSTEM_OPERATIONS_HPP=1 -DHAVE_BOOST_ASSIGN_STD_VECTOR_HPP=1 -DHAVE_BOOST_ALGORITHM_STRING_FIND_HPP=1 -DHAVE_BOOST_FUNCTION_HPP=1 -DHAVE_BOOST_BIND_HPP=1 -DHAVE_ATEXIT=1 -DHAVE_MEMSET=1 -DHAVE_POW=1 -DHAVE_SELECT=1 -DHAVE_SQRT=1 -I.   -pthread -I/usr/local/include  -g -O2 -O0 -ggdb -std=c++0x -Wall -Wextra -Wcast-align -Wpointer-arith -Wno-switch -Wno-sign-compare -Wno-unused-parameter -Wno-cast-align -Wno-overloaded-virtual -DM_DATA_DIR=\"/usr/local/share/vcmi\" -DM_BIN_DIR=\"/usr/local/bin\" -DM_LIB_DIR=\"/usr/local/lib/vcmi\" -DVCMI_DLL -fPIC -c StdInc.h
clang: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated
clang: warning: argument unused during compilation: '-ggdb'
StdInc.h:1:9: warning: #pragma once in main file
#pragma once
        ^
In file included from StdInc.h:3:
./../Global.h:33:10: fatal error: 'array' file not found
#include <array>
         ^
1 warning and 1 error generated.
make[1]: *** [StdInc.h.gch] Error 1
make: *** [all-recursive] Error 1

Oh joy…[/code]

Radzę przejrzeć stare tematy
[forum.vcmi.eu/t/heroes-3-on-mac-os-x/421/1)
I zapytać po angielsku, bo Ivan i Frank Zago polskiego nie znają, a z dużym prawdopdobieństwem to właśnie oni będą mogli pomóc.

Dzięki, zapytam tam. Tylko nie wiem czy wskrzeszać temat czy założyć kolejny… ;f

Po prostu zauważyłem, że duża część teamu jest z pl więc pomyślałem, że nie będzie większej różnicy jak zapytam tutaj :slight_smile:

Wszystko jedno właściwie. Jak nie możesz zdecydować, to wskrześ. :stuck_out_tongue:

Z nieoczywistych powodów cała polska część naszego zespołu i wyłącznie polska część zespołu trwa przy Visualu.

Ale co do tego błędu, to akurat mogę dorzucić swoje trzy grosze. Clang pluje się o brak nagłówka , który został wprowadzony do biblioteki standardowej C++11. Żeby skompilować VCMI potrzebne są względnie nowe wersje kompilatorów (GCC 4.5+, Clang 3.1+), prawdopodobnie masz starszą. Ew. nowy kompilator, ale biblioteka standardowa stara. :stuck_out_tongue:

Z tym akurat się uporałem:

CXXFLAGS="$CXXFLAGS -stdlib=libc++ -Wc++11-extensions"

Później w Global.h warto rzucić:

#ifdef _WIN32
#include <tchar.h>
#else
#include "tchar_amigaos4.h"
#endif

Za includy standardowych libów bo makro _T mu tam z czymś koliduje.

Teraz zamieniam wszystkie lambdy ](a) -> b { … } na te clangowe ^ b (a) { … } albo przepisuję na bezlambdowy kod bo coś mu w nich nie pasuje i się wysegwia przy kompilacji :slight_smile:

A… z czym koliduje? :?
W ogóle, to te tchar-y i przyległości obecnie są praktycznie zbędne, VCMI i tak nie wspiera należycie szerokich napisów na windowsie.

To trochę głupiej roboty będzie. Myślę, że lepiej byś wykorzystał ten czas, zaopatrując się w wersję kompilatora wspierającą lambdy. :wink:

Masz rację.

Skompiluję sobie gcc 4.7.1 i zobaczę bo tego kodu jest trochę za dużo żeby popoprawiać wszystkie niuanse, na które clang psioczy.

Zobaczymy co z tego wyjdzie ;d

Uruchomiłem build process z użyciem gcc 4.7.1. Wszystko idzie w miarę gładko jak na razie.

Powiem jedno, gcc jeest 100x wolniejsze od clanga :smiley:

I problem:

.././../src/lib/CThreadHelper.cpp:7:24: fatal error: sys/prctl.h: No such file or directory

Pod OS X nie ma czegoś takiego jak prctl z racji tego, że to BSDowy system.

I w związku z tym pytanie czy starać się to jakoś podrobić bo jest do czegoś potrzebne czy może po prostu wykomentować?

OK!

Udało mi się skompilować cały pakiet po dorzuceniu -lavutil -lavcodec do LDFLAGS i kilku drobnych zmianach w makrach - głównie w źródłach dotykających ffmpega.

Gorszy problem jest taki, że mam wszystko ładnie w katalogu build/, o którym mowa w vcmi.svn.sourceforge.net/svnroo … ADME.linux i nie za bardzo teraz rozumiem co mam gdzie wrzucić i jeśli chodzi o te configi, dane z HOMM3 Complete i WoG. Co gorsza, nie za bardzo mam pojęcie jak mam postąpić z WoGiem, bo z tego co widzę to on jest w jakimś rarze i execowym “instalatorem” a tego to ja u siebie nie uruchomię :expressionless:

Proszę o pomoc :slight_smile:

Btw. Jeśli to wszystko zadziała to postaram się to wszystko spakować w OSXową paczkę, którą każdy będzie mógł ściągnąć i odpalić na OSX 10.7.

Wcześniejsze posty pisałem niestety jako guest więc muszę dodać kolejny ;f

Udało mi się wrzucić dane wraz z WoGiem do folderu i porobić odpowiednie symlinki. Niestety klient się wywala zaraz po starcie (bez pokazania okna) ze stwierdzeniem:

nooga$ vcmiclient 
Starting... 
Creating console and logfile: 3
vcmiclient(8732,0x7fff79fd3960) malloc: *** error for object 0x10c8bb2b0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

To wróży kolosalne problemy :frowning:

Wrzucam backtrace gdb w miejscu gdzie pękło:

#0  0x00007fff8cf1a6c0 in malloc_error_break ()
#1  0x00007fff8cf1a805 in free ()
#2  0x00007fff8e988702 in std::string::_Rep::_M_dispose ()
#3  0x00007fff8e9892ba in std::string::assign ()
#4  0x0000000102c249aa in boost::filesystem3::detail::directory_iterator_construct ()
#5  0x000000010027aa8f in boost::filesystem3::directory_iterator::directory_iterator (this=0x7fff5fbfe510, [email protected]) at filesystem/v3/operations.hpp:682
#6  0x000000010155d25b in boost::filesystem3::recursive_directory_iterator::recursive_directory_iterator (this=0x7fff5fbfe580, [email protected], opt=recurse) at operations.hpp:850
#7  0x000000010155c08d in CFilesystemLoader::listFiles (this=0x1044086f0, depth=0, initial=<value temporarily unavailable, due to optimizations>) at .././../src/lib/Filesystem/CFilesystemLoader.cpp:61
#8  0x000000010155bc0f in CFilesystemLoader::CFilesystemLoader (this=0x1044086f0, [email protected], depth=0, initial=<value temporarily unavailable, due to optimizations>) at .././../src/lib/Filesystem/CFilesystemLoader.cpp:9
#9  0x0000000101568b42 in CResourceHandler::initialize () at .././../src/lib/Filesystem/CResourceLoader.cpp:311
#10 0x000000010188a5c2 in LibClasses::loadFilesystem () at .././../src/lib/VCMI_Lib.cpp:167
#11 0x0000000100222a64 in SDL_main (argc=1, argv=0x104121f20) at .././../src/client/CMT.cpp:234
#12 0x00000001003d2b71 in -[SDLMain applicationDidFinishLaunching:] ()
#13 0x00007fff8b8c3d0e in __-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_1 ()
#14 0x00007fff8fd4c7ba in _CFXNotificationPost ()
#15 0x00007fff8b8affc3 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#16 0x00007fff8eac54e3 in -[NSApplication _postDidFinishNotification] ()
#17 0x00007fff8eac5249 in -[NSApplication _sendFinishLaunchingNotification] ()
#18 0x00007fff8eac3f10 in -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] ()
#19 0x00007fff8eac3c71 in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
#20 0x00007fff8fd96541 in -[NSObject performSelector:withObject:withObject:] ()
#21 0x00007fff8b8e67c7 in __-[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_1 ()
#22 0x00007fff8b8e574e in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#23 0x00007fff8b8e55dc in _NSAppleEventManagerGenericHandler ()
#24 0x00007fff9271ac25 in aeDispatchAppleEvent ()
#25 0x00007fff9271ab03 in dispatchEventAndSendReply ()
#26 0x00007fff9271a9f7 in aeProcessAppleEvent ()
#27 0x00007fff8a52ad7d in AEProcessAppleEvent ()
#28 0x00007fff8eac107d in _DPSNextEvent ()
#29 0x00007fff8eac0735 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#30 0x00007fff8eabd071 in -[NSApplication run] ()
#31 0x00000001003d2995 in main ()

Chciałbym sprawdzić logi VCMI ale nie za bardzo wiem gdzie one są :smiley:

Jeżeli zmienna środowiskowa HOME jest ustawiona (zwykle wskazuje na katalog domowy), podfolder .vcmi zostanie tam utworzony, gdzie trafią m.in. logi i sejwy. W przeciwnym razie logi są pisane do folderu roboczego.

To dziwne, boost nie powinien się krzaczyć, a przynajmniej nie tak. Konstruktor iteratora, nawet wywołany z bzdurą, powinien się poprawnie wykonać lub rzucić wyjątkiem, tu mamy twardy błąd. Coś może się psuć wcześniej i sączyć cicho jad, albo błąd jest na styku boost<->system.
Rzućmy najpierw okiem na logi, czy wcześniej nic złego się nie dzieje.

Niestety cała zawartość loga to:

Creating console and logfile: 3 

:frowning:

Co do tego błędu to mam dokładnie takie same odczucia - boost nie powinien raczej failować w tak dziwny sposób. Dziwaczne.

Valgrind powinien powiedzieć coś więcej niż gdb na ten temat, ale, jak się okazało, nie umiem wnioskować z outputu valgrinda ;D

Starting... 
Creating console and logfile: 58
==21203== Invalid free() / delete / delete] / realloc()
==21203==    at 0xC764: free (vg_replace_malloc.c:430)
==21203==    by 0x5E06701: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib)
==21203==    by 0x5E072B9: std::string::assign(std::string const&) (in /usr/lib/libstdc++.6.0.9.dylib)
==21203==    by 0x16E89A9: boost::filesystem3::detail::directory_iterator_construct(boost::filesystem3::directory_iterator&, boost::filesystem3::path const&, boost::system::error_code*) (in /usr/local/Cellar/boost/1.49.0/lib/libboost_filesystem-mt.dylib)
==21203==    by 0x10027AA8E: boost::filesystem3::directory_iterator::directory_iterator(boost::filesystem3::path const&) (in /usr/local/bin/vcmiclient)
==21203==    by 0x2125A: boost::filesystem3::recursive_directory_iterator::recursive_directory_iterator(boost::filesystem3::path const&, boost::filesystem3::symlink_option) (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x2008C: CFilesystemLoader::listFiles(unsigned long, bool) const (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x1FC0E: CFilesystemLoader::CFilesystemLoader(std::string const&, unsigned long, bool) (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x2CB41: CResourceHandler::initialize() (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x34E5C1: LibClasses::loadFilesystem() (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x100222A63: SDL_main (in /usr/local/bin/vcmiclient)
==21203==    by 0x1003D2B70: -[SDLMain applicationDidFinishLaunching:] (in /usr/local/bin/vcmiclient)
==21203==  Address 0x25252b0 is in the Data segment of /Users/nooga/local/gcc-4.7.1/lib/libstdc++.6.dylib
==21203== 
==21203== Invalid free() / delete / delete] / realloc()
==21203==    at 0xC764: free (vg_replace_malloc.c:430)
==21203==    by 0x5E06701: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/libstdc++.6.0.9.dylib)
==21203==    by 0x5E072B9: std::string::assign(std::string const&) (in /usr/lib/libstdc++.6.0.9.dylib)
==21203==    by 0x222D1: boost::filesystem3::path::path<boost::filesystem3::directory_entry>(boost::filesystem3::directory_entry const&, boost::enable_if<boost::filesystem3::path_traits::is_pathable<boost::decay<boost::filesystem3::directory_entry>::type>, void>::type*) (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x201B3: CFilesystemLoader::listFiles(unsigned long, bool) const (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x1FC0E: CFilesystemLoader::CFilesystemLoader(std::string const&, unsigned long, bool) (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x2CB41: CResourceHandler::initialize() (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x34E5C1: LibClasses::loadFilesystem() (in /Users/nooga/vcmi2/trunk/build/lib/.libs/libvcmi.0.dylib)
==21203==    by 0x100222A63: SDL_main (in /usr/local/bin/vcmiclient)
==21203==    by 0x1003D2B70: -[SDLMain applicationDidFinishLaunching:] (in /usr/local/bin/vcmiclient)
==21203==    by 0x2A1BD0D: __-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_1 (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==21203==    by 0x272D7B9: _CFXNotificationPost (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==21203==  Address 0x25252b0 is in the Data segment of /Users/nooga/local/gcc-4.7.1/lib/libstdc++.6.dylib
==21203== 
	 Initialization: 630
terminate called after throwing an instance of 'std::runtime_error'
  what():  Resource with name ALL/CONFIG/FILESYSTEM and type TEXT wasn't found.

Obejrzę sobie ten CFilesystemLoader::listFiles ale prawdopodobnie przyczyna nie jest z tym związana hyh.

Edit: Po krótkim googlaniu zdaje się, że to jest jakiś bug boosta w związku z gcc 4.7.1 i OSX -> boost.2283326.n4.nabble.com/Re-f … 33197.html

Edit2: Problemy w runtime mogły brać się stąd, że boost był skompilowany innym kompilatorem niż vcmi.

Zbudowałem potrzebne liby boosta 1.50 w tym samym środowisku, w którym buduję vcmi i staram się teraz ponownie zbudować vcmi. Niestety znowu natykam się na errory w compile time, np.: pastie.org/private/pkkcx0ptgfvjhjpepdelhw

Wygląda mi to na jakiś problem z includami ale nie umiem tego rozwiązać :frowning: help plx?

A tak, to całkiem prawdopodobne źródło problemów. Wszystkie biblioteki mające interfejs w C++ powinny być zbudowane tym samym kompilatorem i (w miarę) tymi samymi opcjami.

Dziiiwne. Jakby widziało dwie wersje Boosta na raz.
a) Wyczyść swój fodler roboczy z plików generowanych przez kompilator (zwłaszcza jakieś prekompilowane nagłówki czy coś), przebuduj na czysto.
b) Jeśli zbudowałeś Boosta 1.50 to upewnij się, że nie kompilator nie widzi śladów Boosta 1.49 (czy nie ma gdzieś jakichś starych ścieżek zapisanych gdzieś przez autotools itp).

Dałem make clean i znów make ale mam to samo :frowning:

Co jest dziwne to to, że patrząc na ten listing errorów nie widzę żadnych innych ścieżek poza /usr/local/include/boost/ - a tam wszystko jest nowe (tzn z boosta 1.50).

Co więcej, wydaje mi się, że te errory są w momencie gdy używane jest asio - tak jakby rzeczy includowane przez asio konfliktowały się z rzeczami includowanymi z Global.h czy coś.

A jak? ;D Mam nikłe pojęcie o autotools :<

Problem pojawia się tylko przy kompilacji libvcmi_la-Connection.lo kiedy w grę w chodzi boost/asio.

Błąd bezwzględnie wygląda na pozostałość po Booście 1.49 kolidującą z nowym.

Za grosz nie znam się na autotools, ale gdzieś muszą pozostawać pozostałości po poprzedniej próbie budowania. Stawiam, że to prekompilowany nagłówek w libie. Prejrzyj folder, w którym budujesz i jego podfoldery, gdzieś tam będą jakieś binarne pliki wygenerowane przez kompilator, pewnie grube. Wywal.

Albo sprytniej. Zmodyfikuj plik Global.h, tak aby miał najnowszą datę modyfikacji. To powinno zmusić make’a, by elegancko przebudować wszystko. :>

Miałeś rację :slight_smile:

Wszytsko robię w build/ no i make clean nie pozbył się precompiled headers z src/ (gch). Wywaliłem je ręcznie, znowu make clean i build;
Aktualnie projekt się buduje poprawnie i w zasadzie bez warningów

Niestety w runtimie dalej ten sam babol. :frowning:

Jedyne co zmieniłem w kodzie projektu to wyciąłem prctl(PR_SET_NAME, name.c_str(), 0, 0, 0); w CThreadHelper - OS X tego nie obsługuje w żaden sposób. Ale mimo to uważam, że to nie powinno wywoływać tak głupiego efektu.

Będę próbował dalej…