Dnia 2011-10-21, pią o godzinie 01:31 +0200, Tomasz Wasilczyk pisze: > W dniu 20 października 2011 23:16 użytkownik Wojtek Kaniewski > <wojte...@toxygen.net> napisał: > > Bardzo dobrze, że usunąłeś ioctl(), bo ta funkcja > > zawierała kod zupełnie niezwiązany z libgadu. > > Nie wiem, do czego ona służy, ale libgadu ją wykorzystuje > (src/common.c:267), a cygwin nie dostarcza.
Jeśli jest FIONBIO, a nie ma ioctl() to prawdopodobnie powinniśmy użyć ioctlsocket(). Mógłbyś sprawdzić, czy dodanie #define ioctl ioctlsocket do network.h pomoże? > Przeoczyłeś dwie zmiany, a brak ioctl rzuca błędem. Ponadto getsockopt > jest pod windowsem chyba trochę inne (patrz pierwszy patch z > gg_win32_getsockopt) i rzuca warningami o złym typie parametrów. > Ostatni commit z send/recv też dodaje mnóstwo warningów o typowaniu. O ile cygwin sobie z tym poradzi, to pewnie MSVC++ będzie już miał z typami problem. Faktycznie, makra rzutujące się przydadzą. > Dzięki za włączenie zmian, w tej chwili pidginowy fork na poziomie > kodu źródłowego już praktycznie niczym się nie różni od wersji > pierwotnej. Praktycznie, tzn. nazwy plików nagłówkowych internal.h, > debug.h i config.h są zmienione, bo konfliktowały z tak samo nazwanymi > plikami w Pidginie. Dziwne. libgadu jest kompilowane razem z pluginem, jako biblioteka statyczna czy może inaczej? > Prawdopodobnie w libgadu mógł by się przydać resolver dla win32, który > udało mi się wyciągnąć poza źródła libgadu dzięki dodaniu > gg_global_set_custom_resolver. Bo w tej chwili windowsowe buildy będą > bez żadnego. Ale to już nie jest istotne z punktu widzenia libpurple. > Za to by się pewnie mogło przydać w Kadu. Ten resolver z Kadu wygląda sensownie, więc postaram się go dorzucić. > - ktoś wspominał (nie pamiętam kto, rozmawiałem o tym parę miesięcy > temu), żebym lepiej (wtedy) nie próbował implementować obsługi Mozilla > NSS (obok GnuTLS i OpenSSL), bo będzie mocno przebudowywany kod z tym > związany. Czy dobrze widzę, że to się już stało i mogę w jakiejś tam > przyszłości do tego zacząć zaglądać? Pamiętam, że ktoś chciał się za to zabrać, ale jak zwykle nie mogę znaleźć maila. Przy trzeciej bibliotece SSL faktycznie dobrze by było jakoś to wydzielić, żeby kod nie był pocięty #ifdefami, ale jeśli chcesz się za to zabrać, to nie krępuj się. > - ludzie od libpurple wspominali, że fajnie by było, jakby libgadu > pozwalało przekazać obsługę połączeń aplikacji, żeby można było np. > skorzystać z SOCKS proxy. Np. w taki sposób, jak to się udało z > gg_global_set_custom_resolver. Domyślam się, że to jest związane z > send/recv? Nie zagłębiałem się w temat, więc być może popełniłem w tym > punkcie jakąś głupotę. Jesteś w stanie pokazać jakąś dokumentację libpurple dotyczącą obsługi SOCKS? Nie wiedząc czego oczekują, ciężko mi się wypowiedzieć :) Pozdr, Wojtek _______________________________________________ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
