Kompilację biblioteki na systemach uniksowych lub uniksopodobnych (np. Windows + Cygwin) przeprowadza się według typowego schematu:

$ ./configure
$ make
# make install

Gdzie ostatnią komendę wykonuje się z prawami administratora. Aby zainstalować bibliotekę w katalogu użytkownika, można wykonać polecenia:

$ ./configure --prefix=/katalog/użytkownika/libgadu
$ make
$ make install

Następnie, aby użyć lokalnie zainstalowanej kopii biblioteki, zwykle należy dodać do zmiennej CFLAGS opcję -I/katalog/użytkownika/libgadu/include , a do LDFLAGS opcję -L/katalog/użytkownika/libgadu/lib.

Kompilacja skrośna

Przy kompilacji skrośnej konieczne jest użycie parametru –with-c99-vsnprintf lub –without-c99-vsnprintf w skrypcie configure, który mówi o tym, że funkcje rodziny sprintf() na docelowej platformie są zgodne lub niezgodne ze standardem C99. Jeśli żaden z powyższych parametrów nie zostanie użyty, skrypt configure spróbuje uruchomić program testowy, co przy kompilacji skrośnej się nie powiedzie.

Rozwiązywanie nazw

Biblioteka oferuje dwa sposoby rozwiązywania nazw serwerów w trybie asynchronicznym: za pomocą osobnego procesu lub za pomocą osobnego wątku. Druga możliwość jest zalecana dla programów, które korzystają z wątków systemowych, ponieważ użycie funkcji fork() do tworzenia procesu potomnego w aplikacji korzystającej z wątków może powodować problemy. W wersjach wcześniejszych niż 1.9.0 sposób rozwiązywania nazw był wybierany na etapie kompilacji, co powodowało problemy, gdy w systemie były zainstalowane aplikacje korzystające i niekorzystające z wątków systemowych. Od wersji 1.9.0, jeśli jest to możliwe, kompilowane są obie wersje, a wybór jest dokonywany przez aplikację.

Od wersji 1.12.0 domyślna metoda to GG_RESOLVER_PTHREAD (użycie wątków pthread), bez możliwości wybrania priorytetu na etapie kompilacji. Jeżeli ta jest niedostępna (lub zostanie wyłączona przełącznikiem –without-pthread), użyta zostanie – w zależności od systemu – GG_RESOLVER_WIN32 (użycie natywnych wątków win32) lub GG_RESOLVER_FORK (użycie osobnego procesu). W razie potrzeby można użyć własnej implementacji, ustawianej za pomocą funkcji gg_*_set_custom_resolver().