Autor Wątek: Cross-kompilacja SDL_gfx pod MinGW z GCC4  (Przeczytany 2633 razy)

Offline vshader

  • Użytkownik
    • VShader - strona domowa

# Marzec 01, 2009, 13:41:16
Hej, męczę się z tym już drugi dzień, przekopałem setki stron z googla. Niestety, nie udało mi się znaleźć rozwiązania, tak więc pytam na forum.

W skrócie: postanowiłem przeportować mój projekt na Windows. Jako że nie mam wielkiej ochoty na powrót do Windows, zdecydowałem się na kompilację skrośną (cross-compilation). Pobrałem stabilne MinGW, jednak okazało się że obsługuje tylko GCC 3, a ja używam sporo rozszerzeń GNU i C++0x. Przebrnąłem więc przez ręczną kompilację alfy MinGW dla GCC 4 (3 dni!). W końcu się udało, kompilator zdaje się pracować sprawnie.  8)

Potem zabrałem się za rekompilację bibliotek. Większość poszła bez problemu. W tej chwili zostało mi już tylko SDL_gfx które za nic w świecie nie chce się dać się skompilować.

To znaczy - właściwie to się kompiluje. Sęk w tym, że powstaje tylko statyczna biblioteka. Niestety, SDL_gfx jest dytrybuowane na zasadach licencji LGPL, a więc, nie chcąc GPLować (:D) mojego projektu muszę linkować dynamicznie. Dlatego też potrzebuję DLL.

Co konkretnie się dzieje:
Wywołuję ./configure z parametrami
./configure --enable-shared=YES --bindir=/usr/local/i586-pc-mingw32/bin --prefix=/usr/local/i586-pc-mingw32 --target=i586-pc-mingw32 --host=i586-pc-mingw32 --with-sdl-prefix=/home/vshader/mingw/SDL-1.2.13Configure rusza. Niestety, pomimo nawet jawnego wymuszenia --enable-shared=yes (co jest również opcją domyślną) już podczas konfiguracji dostaję informację że zbudowanie "shared library" nie nastąpi:
checking if the linker (/usr/local/i586-pc-mingw32/bin/ld) is GNU ld... yes                                                 
checking whether the linker (/usr/local/i586-pc-mingw32/bin/ld) supports shared libraries... yes                             
checking command to parse /usr/bin/nm -B output... /usr/bin/nm: conftest.o: File format not recognized                       
/usr/bin/nm: conftest.o: File format not recognized                                                                         
failed                                                                                                                       
checking how to hardcode library paths into programs... immediate                                                           
checking for /usr/local/i586-pc-mingw32/bin/ld option to reload object files... -r                                           
checking dynamic linker characteristics... Win32 ld.exe                                                                     
checking if libtool supports shared libraries... yes                                                                         
checking if package supports dlls... no                                                                                     
checking whether to build shared libraries... no
checking whether to build static libraries... yes                                                                           
checking for objdir... .libs

Podczas intensywnego googlowania trafiłem na informację jakoby system budowania w SDL_gfx nie był w stanie stworzyć DLL a więc autor sugeruje wymuszenie linkowania statycznego. Niestety, jak już powiedziałem ta opcja nie wchodzi w grę.

Kompletnie nie wiem, czym może być to spowodowane. Jeżeli jest to rzeczywiście usterka w systemie budowania SDL_gfx (a wszystko na to wskazuje), to jak mogę to poprawić (nie jestem geniuszem jeśli chodzi o configure, makefile i te sprawy)?

Liczę że trafi się ktoś mądrzejszy, kto będzie wiedział o co w tym wszystkim chodzi.
Pozdrawiam  :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

st3tc

  • Gość
# Marzec 01, 2009, 13:47:06
Przebrnąłem więc przez ręczną kompilację alfy MinGW dla GCC 4 (3 dni!). W końcu się udało, kompilator zdaje się pracować sprawnie.  8)
Abstrahując od SDL (bo nie używam :) ), czemu po prostu nie zassałeś sobie TDM-a ?  ( http://www.tdragon.net/recentgcc/  ). Gość dwa tygodnie temu wystawił już wersję 4.3.3 :), ma wszystko co trzeba nawet openmp :)

Offline vshader

  • Użytkownik
    • VShader - strona domowa

# Marzec 01, 2009, 13:57:08
Przebrnąłem więc przez ręczną kompilację alfy MinGW dla GCC 4 (3 dni!). W końcu się udało, kompilator zdaje się pracować sprawnie.  8)
Abstrahując od SDL (bo nie używam :) ), czemu po prostu nie zassałeś sobie TDM-a ?  ( http://www.tdragon.net/recentgcc/  ). Gość dwa tygodnie temu wystawił już wersję 4.3.3 :), ma wszystko co trzeba nawet openmp :)
Ups, no to wtopa  :o Nie miałem pojęcia że takie coś istnieje. Na stronach MinGW nie trafiłem na żadną o tym informację.
Rzeczywiście, podczas googlowania gdzieś przwinął sie ten skrót. Niestety, nie zagłębiłem się w tym kierunku, czego teraz szczerze żałuję  :P

W każdym razie na razie mam MinGW ustawione i chwilowo nie będę tego zmieniał. Chcę najpierw skompilować wreszcie mój projekt.  :)

Offline Zombiak

  • Użytkownik

# Marzec 01, 2009, 15:40:07
Abstrahując od SDL (bo nie używam :) ), czemu po prostu nie zassałeś sobie TDM-a ?  ( http://www.tdragon.net/recentgcc/  ). Gość dwa tygodnie temu wystawił już wersję 4.3.3 :), ma wszystko co trzeba nawet openmp :)
Fajnie, ale c++0x to dalej nie kompiluje ;)

C:\Users\Zombiak\cbp\foo>type main.cpp
#include <iostream>
#include <vector>

using namespace std;

int main()
{
    int v1[] = {1,2,3,4};

    auto a =v1[1];

    for(int &x : v1)
        cout << x << endl;
    cout << "Hello world!" << endl;
    return 0;
}

C:\Users\Zombiak\cbp\foo>g++ -std=gnu++0x main.cpp
main.cpp: In function 'int main()':
main.cpp:10: error: ISO C++ forbids declaration of 'a' with no type
main.cpp:12: error: a function-definition is not allowed here before ':' token
main.cpp:15: error: expected primary-expression before 'return'
main.cpp:15: error: expected `)' before 'return'

C:\Users\Zombiak\cbp\foo>g++ -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.3.3-mingw/configure --host=i386-pc-mingw32 --build=x86
_64-unknown-linux-gnu --target=i386-pc-mingw32 --prefix=/home/gfortran/gcc-home/
binary/mingw32/native/x86_32/gcc/4.3.3 --with-gcc --with-gnu-ld --with-gnu-as --
disable-shared --disable-nls --disable-tls --with-gmp=/home/gfortran/gcc-home/bi
nary/mingw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw3
2/native/x86_32/mpfr --enable-languages=c,fortran,c++ --with-sysroot=/home/gfort
ran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.3.3 --enable-libgomp --enable-thr
eads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.3.3 (GCC)

st3tc

  • Gość
# Marzec 01, 2009, 16:55:05
Abstrahując od SDL (bo nie używam :) ), czemu po prostu nie zassałeś sobie TDM-a ?  ( http://www.tdragon.net/recentgcc/  ). Gość dwa tygodnie temu wystawił już wersję 4.3.3 :), ma wszystko co trzeba nawet openmp :)
Fajnie, ale c++0x to dalej nie kompiluje ;)
Żaden gcc nie obsługuje c++0x :). 4.3 obsługuje część (małą bo małą - i akurat nie wie co to auto) - ale to i tak lepiej niż używać starego 3.4 ;). BTW: 4.4 też nie obsługuje 0x (akurat auto mu wpadło do listy obsługiwanych) - tylko mały wycinek fjuczerasów :)
« Ostatnia zmiana: Marzec 01, 2009, 17:00:53 wysłana przez st3tc »

Offline vshader

  • Użytkownik
    • VShader - strona domowa

# Marzec 03, 2009, 05:31:50
Ok, problem rozwiązany  :)
Niestety, metodą zasługującą na potępienie  :-\. Jako że nie trawię configurów i makefile (używać ujdzie, tworzyć nie) napisałem skrypt shella który konfiguruje mi tą libkę i wywołuje linker "ręcznie".

Zamieszczam go dla potomnych, może komuś się przyda  :) (wystarczy zmienić ścieżki)
cd SDL_gfx-2.0.18
make clean
./configure --enable-shared=YES --bindir=/usr/local/i586-pc-mingw32/bin --prefix=/usr/local/i586-pc-mingw32 --target=i586-pc-mingw32 --host=i586-pc-mingw32 --with-sdl-prefix=/home/vshader/mingw/SDL-1.2.13
make
i586-pc-mingw32-gcc -shared *.o -o SDL_gfx.dll -L/home/vshader/mingw/lib -lSDL

A co do tej całej afery z GCC 4 to uparłem się na niego głównie ze względu na notoryczne nadużywanie w moim kodzie operatora typeof, który nawet nie jest przewidziany (chyba) w C++0x, a jest jedynie rozszerzeniem GNU  :).