aMule Forum
English => Compilation problems => Topic started by: DLH on December 17, 2008, 09:52:06 PM
-
I've been trying to cross-compile aMule for Windows using mingw32 on Mandriva 2008.1. I haven't found any relevant howto's so it's been a trial and error process, but still I seemed to be making good progress until it came to amule itself. I'm not even using SVN, just the same stable 2.2.2 source that compiled for Linux like a breeze. I managed to compile wxWidgets with mingw32, which would seem like the biggest hurdle to overcome. However when I run configure in amule sources it keeps getting interrupted with a "checking for zlib >= 1.1.4... no". I have zlib-1.2.3 installed system-wide(and *-devel just in case); I also compiled and installed it in a local build tree and then in /usr/local, but no matter where I point the configure script to look for it(--with-zlib=/x/y/z) or let it auto-detect, the same error returns. It's even harder to understand given that configure detects such system-wide dependencies like flex or bison. I would appreciate any meaningful advice.
-
Did you compile and install zlib for mingw? The Linux version will not work when you try to compile a Windows binary.
(Usual steps for cross-compile with mingw: libiconv, gettext, zlib, crypto++, wxwidgets, amule)
-
How do you cross-compile something that can't use HOST= option( e.g. zlib) or even 'configure' script at all( crypto++) ? Windows MinGW howto only calls for zlib, wxWidgets and crypto++, so why are more items required to cross-compile ?
-
Cross-compilation means using a different compiler to create code for the target platform and linking against libraries created for the target platform.
The first is done by replacing the compiler command. Set CC="i486-mingw32-gcc" and CXX="i486-mingw32-g++" and you should be done. The cross-compiler environment will reside in /usr/i486-mingw32/ and contain the include, lib,... folders necessary for compiling. Now it gets a bit more complicated as tools like ranlib or ar will sometimes need their own versions (i.e. i486-mingw32-ranlib and i486-mingw32-ar), so this is something you have to manually hack in the crypto++-GNUmakefile. Other than that it's just building all necessary libraries for the target platform (and installing them into the cross-compiler enviroment at /usr/i486-mingw32/) and then building the application.
Please be aware that your mingw version might be called i686-mingw32, in this case names will be i686-mingw32-gcc and so on.
Short: Change usual build tools against cross-compiler tools and use them to build the environment.
Edit: Here's a list of Archlinux mingw32-pkgbuilds (build recipes) in aur: http://aur.archlinux.org/packages.php?K=mingw32
-
export HOST=mingw32
export MINGW_INSTALL_PREFIX=/usr/local/mingw32
make libz.a \
-f win32/Makefile.gcc \
CC=$HOST-gcc \
AR=$HOST-ar
mv libz.a $MINGW_INSTALL_PREFIX/lib/
mv zconf.h $MINGW_INSTALL_PREFIX/include/
mv zlib.h $MINGW_INSTALL_PREFIX/include/
export HOST=mingw32
export MINGW_INSTALL_PREFIX=/usr/local/mingw32
make ISMINGW=1 \
UNAME=mingw32 \
CC=$HOST-gcc \
CXX=$HOST-g++ \
AS=$HOST-as \
LD=$HOST-ld \
AR=$HOST-ar \
RANLIB=$HOST-ranlib
make install PREFIX=$MINGW_INSTALL_PREFIX
-
Wow, thanks for the pointed replies. Since I posted my last question I've been going through some makefiles and configure scripts and after a few attempts I managed to nail the right version of zlib by inserting these flags before ./configure
CC=i586-pc-mingw32-gcc RANLIB=i586-pc-mingw32-ranlib LD=i586-pc-mingw32-ldNow I have to redo crypto++ since setting CXX wasn't enough. Is compiling gettext really necessary ? I remember that it's huge and it'd probably take an all day ride on my ancient choo-choo.
-
Is compiling gettext really necessary ?
No. If you have the native gettext tools on your system, it will work. They are used just to compile the translations. The only program that really uses gettext is amuleweb, which, unfortunately, doesn't work on MSW.
If you don't have gettext at all or just don't want to bother with it, you can configure aMule with --disable-nls.
-
I'm almost done here, but I keep getting stuck on libgeoip cross-compilation. Could someone advise me what do I need to modify/add to make it happen ? The most recent versions trip up right away, so I tried regressively older versions and I got further along with those but it breaks with errors nevertheless
Making all in apps
make[1]: Entering directory `/home/tweaker/mingw32/build/GeoIP-1.4.1/apps'
/bin/sh ../libtool --mode=link i586-pc-mingw32-gcc -g -O2 -o geoiplookup.exe geoiplookup.o ../libGeoIP/libGeoIP.la
i586-pc-mingw32-gcc -g -O2 -o geoiplookup.exe geoiplookup.o ../libGeoIP/.libs/libGeoIP.a
../libGeoIP/.libs/libGeoIP.a(GeoIP.o): In function `GeoIP_open':
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:500: undefined reference to `_WSAStartup@8'
../libGeoIP/.libs/libGeoIP.a(GeoIP.o): In function `_GeoIP_lookupaddress':
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:607: undefined reference to `_inet_addr@4'
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:648: undefined reference to `_ntohl@4'
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:637: undefined reference to `_gethostbyname@4'
../libGeoIP/.libs/libGeoIP.a(GeoIP.o): In function `GeoIP_assign_region_by_inetaddr':
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:803: undefined reference to `_ntohl@4'
../libGeoIP/.libs/libGeoIP.a(GeoIP.o): In function `_get_region':
/home/tweaker/mingw32/build/GeoIP-1.4.1/libGeoIP/GeoIP.c:847: undefined reference to `_htonl@4'
collect2: ld returned 1 exit status
make[1]: *** [geoiplookup.exe] Error 1
make[1]: Leaving directory `/home/tweaker/mingw32/build/GeoIP-1.4.1/apps'
make: *** [all-recursive] Error 1
I tried disabling either shared or static in configure but to no avail. Here are the sources:http://geolite.maxmind.com/download/geoip/api/c/ (http://geolite.maxmind.com/download/geoip/api/c/)
-
Compiling GeoIP with mingw is somewhat tricky.
I have a working patchset for GeoIP-1.4.4, see attachment. It was created to be used from native MinGW/MSYS environment, so you'll have to edit the tool names in Makefile.mingw
After applying the patches, 'make -f Makefile.mingw' will produce the libraries (both shared and static by default).
-
Awesome ! I got the patches merged and I know how to edit the tools, but one section in the makefile concerns me
DATADIR = c:/GeoIP
CONFDIR = c:/GeoIP
Should I do anything about those or just ignore them ? Are those paths going to be hard-coded in aMule ?
-
You may safely ignore them. CONFDIR is only used by the geoipupdate executable, DATADIR is not used on MSW targets.
-
So close but no cigar ! I spent a few hours compiling and was getting ready to put my hands on a brand new binary, when it got snatched from me again
Linking amule.exe
/usr/local/bin/../lib/gcc/i586-pc-mingw32/3.4.5/../../../../i586-pc-mingw32/lib/libstdc++.a(stubs.o):stubs.c:(.text+0x60): multiple definition of `_expf'
amule-DownloadClient.o:/home/tweaker/mingw32/build/amule-2.2.2/src/GuiEvents.h:(.text$expf[_expf]+0x0): first defined here
collect2: ld returned 1 exit status
make[3]: *** [amule.exe] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Any ideas, please ?
-
Are you saying that, at the end, you'll be able to have a Win32 amule or amulegui including GeoIP support?
If you want to run it on Windows, why don't you compile it on Windows with the free MS-VisualC++-Express ? GeoIP is also supported in the MSVC project (SVN version only).
Moreover, do you think patches can be adapted to GeoIP 1.4.5?
Why ? There's no benefit in 1.4.5. Just a load of IPV6 stuff that breaks everything. And all the #if !defined(WIN32) && !defined(WIN64) only prooves they have no clue about Windows and never tried to compile it. >:(
-
I tried to statically link the GeoIP code (--with-geoip-static) but it didn't work with i386-mingw32-ld. So amulegui.exe requires GeoIP.dll .
If you remove the shared library (.dll) and the import library (.dll.a), ld should link with the static library. Or, if you don't build them.
There are still minor problems in the make phase, [...]
What problems?
-
Thanks for the report and the tests. Static link with GeoIP is now fixed in rev. 9371.
-
Please re-attach your patch, because the attached file is 0-bytes long...