Witajcie ponownie!
Linker nie widzi bibliotek, no, czyli instalacja się jednak nie udała.
To bardzo skomplikowany problem. Czy przewidujesz nagrody za jego rozwiązanie?
To normalne. Właściwie nie masz problemów z programowaniem tylko z linkowaniem, a z tym zawsze są problemy pod niepopularnymi środowiskami. Dlatego może łatwiej byłoby Ci z Visual Studio Community 2015 (jest darmowe).
Dla pewności mówisz o tym http://www.sfml-dev.org/tutorials/2.3/start-cb.php ?
Nie próbuj ich zrozumieć, one są zupełnie niezrozumiałe. Undefined reference pojawia się gdy linker nie może znaleźć danej funkcji np:
#include <iostream>
using namespace std;
void ijjj();
int main()
{
ijjj();
cout << "Hello world!" << endl;
return 0;
}
Tutaj te funkcje powinny leżeć w plikach *.a (dokładniej leżą w dll, ale nie chcę zbytni mieszać). Czy masz dopisane sfml-graphics (i inne) tak ja na rysunku dla Release ze strony na którą się powoływałaś? I czy w identycznej kolejności?
Dla debug mają być takie same tylko z literką -d.
Tutaj masz obszerniejszą instrukcję po polsku:
Masz tam więcej bibliotek dopisanych bo oni planują korzystać z audio i sieci.
Ewentualnie korzystasz z bibliotek nie dla tego gcc który jest wbudowany w Codeblocks. Dla tej wersji nie ma wersji binarnej wiec trzeba użyć starszej.
Na szybko:
- Ściągnij SFML-GCC 4.8.1 TDM (SJLJ) - 32-bit
http://mirror1.sfml-dev.org/files/SFML-2.3.2-windows-gcc-4.8.1-tdm-32-bit.zip
Rozpakuj na D. Tak by mieć plik pod tą pełną ścieżką D:\SFML-2.3.2\lib\libFLAC.a
- Odinstaluj codeblocks testSFML.zip i zainstaluj codeblocks-16.01mingw-setup.exe na D:\Program Files (x86)\CodeBlocks
D:\Program Files (x86)\CodeBlocks\codeblocks.exe
- Ściągnij ten projekt z załącznika, tam masz wszystko ustawione jak należy (odwołuje się do ścieżek wyżej opisanych).
Rozpakuj go na D. By uzyskać D:\testSFML\testSFML.cbp (ścieżka jest ważna!)
- Spróbuj skompilować go pod Release i Debug. Powinno się skompilować bez problemu.
By wyprodukowany exe się uruchomił potrzebuje dllów. Więc wyszukujesz w podkatalogach Codeblock libgcc_s_sjlj-1.dll, libstdc+±6.dll i mu je kopiujesz (albo możesz ustawić tak jak w polskiej instrukcji linkowanie statyczne). Z D:\SFML-2.3.2\bin też mu kopiujesz biblioteki.
Możesz tez w notatniku porównać mój plik cbp z twoim.
Napisz czy zadziałało.
@KamilDz CodeBlocks to nie popularne środowisko? Prawie spadłem z krzesła. Jedno z najpopularniejszych środowisk C++, bo Visual Studio jest tylko na Windows, a CB jest na kilka platform. No i niby dlaczego zakładasz, że pod Visual Studio będzie łatwiej? “Trudność” linkowania bibliotek jest identyczna w każdym środowisku, w każdym po prostu robi się to inaczej. Polecanie innego środowiska, bo ktoś nie umie zalinkować bibliotek to najgłupsze możliwe rozwiązanie, bo co ma środowisko do umiejętności programistycznych? A najgorszą rzeczą, jaką może zrobić programista, jest uzależnienie się tylko od jednego IDE. IDE to tylko narzędzie wspomagające prace i dobry programista powinien być w stanie pracować na każdym, jakie mu dadzą, a nawet bez IDE. Pliki a również zawierają funkcje, dokładnie tak samo jak dll. a jest biblioteką linkowaną statycznie, dll biblioteką linkowaną dynamicznie. Jak już pomagasz, to chociaż nie wypisuj bzdur.
Autorka zapewne korzystała ze strony którą podałeś, bo wrzuciła do pierwszego posta kod źródłowy z tej strony. Na polskiej stronie jest lepiej i bardziej łopatologiczne wyjaśnione, więc lepiej żeby się z tym zapoznała. Już link podałem, ale powtórzę:
No przecież nie chodzi o CodeBlocks tylko MinGW (port GCC) w nim zaszyty. GCC pod Windows to nisza. Do tego to się rozbija na niekompatybilne ze sobą wersje (czyli powstaje nisza w niszy), a to oznacza brak wsparcia od twórców bibliotek. Zresztą, niekompatybilność mutacji GCC masz opisaną na stronie którą podałeś.
Windosowski CodeBlocks który podałem korzysta TDM-GCC (version 4.9.2, 32 bit, SJLJ), do wersji o tym numerku nie ma plików *.a na stronie twórców (bo autorzy sobie to olali, no bo jak piszą w końcu każdy może sobie sam z build ować). Jest do wersji o starszym numerku (4.8.1), sprawdziłem i działa, ale przed sprawdzeniem to pewności nie miałem.
VC jest popularny więc go nie olewają, do tego wersja z danego roku jest zawsze kompatybilna ze sobą.
Czyli problem rozbija się o dostępność plików *.a i *.lib w internecie.
Zapewne chodzi Ci o to moje słowa "Tutaj te funkcje powinny leżeć w plikach *.a (dokładniej leżą w dll, ale nie chcę zbytni mieszać). " Otóż masz racje, że funkcje mogą leżeć w plikach *.a, ale w tym akurat wypadku nie jest to prawdą. Popatrz na przykład do którego podałeś linki. Tam podaje się linkierowi pliki *.a, a na końcu piszą by nie zapomnieć skopiować plików *.dll. Po prostu pliki *.a w tym wypadku są “interfejsami” do wywoływania funkcji z dll. Skompilowane funkcje siedzą właśnie w dll.
No to precyzuj o co ci chodzi. Pod Windowsem to się zgodze, że Visual Studio jest najpopularniejszy. Co do wsparcia, to nie wiem czy zauważyłeś, ale SFML to biblioteka multiplatformowa, więc lepiej wspiera GCC niż VS. Problem polega na tym, że GCC rozwija się w inny sposób niż VS i to może porwadzić do sytuacji, że nowa wersja GCC nie działa z biblioteką skompilowaną pod starą wersje. Zawsze mozesz sobie skompilować ją, SFML korzysta z cmake, a jego kompilacja to prosta sprawa.
Nie są wspomniane bezpośrednio, ale przecież to widać na ustawieniach linkiera na screene.
http://www.sfml-dev.org/tutorials/2.3/images/start-cb-link-libs.png
Na screenie napis sfml-graphics oznacza, że linker użyje pliku lib sfml-graphics.a.
W tym pliku nie ma funkcji w postaci skompilowanej, to jest tylko “interfejs” do dll więc plik wykonywalny by się uruchomić będzie żądał dll.
Masz też w paczce plik lib sfml-graphics_s.a możesz go podać do linkiera i wtedy program nie będzie żądał dll bo funkcje są w tym pliku a. Teraz powinieneś wszystko zrozumieć.
Może to i jest prawda bo piszą, że “On Windows and Mac OS X, all the required dependencies are provided alongside SFML so you won’t have to download/install anything else. Building will work out of the box.” Tylko pewnie dostarczą gotowe pliki *.a zależności, a lepiej byłoby samemu je skompilować. Z czego pewnie zrobi się kilka godzin. Zapewne kompilacja ich nie będzie taka prosta.
Podejrzewam też że Mingw z Codeblocks okaże się zbyt okrojony by przeprowadzić ta operację.
Jak linkujesz statycznie, to dll wcale nie są brane pod uwage. Funkcje siedzą też w plikach a, będących statycznymi bibliotekami… Skompiluj statycznie, pokasuj wszelkie dll i zobacz czy odpali. Odpali bez problemów. Biblioteki statyczne(w tym wypadku np. libsfml-graphics_s.a) także zawierają skompilowane funkcje, nie tylko dll je zawiera. Trochę się zamotałem, bo na Linuksie biblioteka to plik lib, a na Windowsie to plik a, ale z całą resztą miałem racje. Jak nie wierzysz, to powtarzam, skompiluj statycznie i najlepiej spróbuj na innej maszynie, na której nie ma wymaganych dll - program będzie działał bez problemu. Zresztą porównaj sobie rozmiar np. libsfml-system-s-d.a i sfml-system-d-2.dll(wybrałem paczke dla MinGW). To pierwsze waży 120kB, a to drugie 113kB, więc to chyba mówi samo za siebie. Plik a waży mniej wiecej tyle samo co dll, to znaczy, że także zawiera funkcje. Pliki a faktycznie tutaj są tylko interfejsami, ale za to pliki a z dopiskiem -s w nazwie zawierają już w sobie funkcje, dokładnie tak samo jak DLL.
Ciesze się, że zrozumiałeś.
Chodzi o to, że zależności masz dostarczane w postaci plików *.a które nie muszą działać na twojej mutacji gcc. Jeśli masz wszystkie pliki *.a to nie musisz nawet buildować SFML.
MinGW to nie tylko port GCC. MinGW to skrut od Minimalist GNU for Windows.
“MinGW, a contraction of “Minimalist GNU for Windows”, is a minimalist development environment for native Microsoft Windows applications.”
Skompilowanie aplikacji linuksowych jest łatwiejsze na linuksie, bo pod niego były pisane. Pod MinGW pojawiają się problemy bo to środowisko niszowe i nie ma wsparcia twórców.
Mogłeś odrazu sprecyzować. Pisałeś, że DLL zawierają funkcje, a pliki a to tylko interfejs. Problem w tym, że biblioteki statyczne, które też zawierają funkcje także mają rozszerzenie a.