From: Luke D. <cod...@ho...> - 2003-03-19 10:35:00
|
>From: Pieter Thysebaert <pie...@in...> >To: Ross Burton <r.b...@18...>,min...@li... >Subject: Re: [Mingw-users] Cross-compiling libiconv >Date: Wed, 19 Mar 2003 09:48:38 +0100 > >On Tuesday 18 March 2003 16:02, Ross Burton wrote: > > Hi, > > > > I am trying to build a GTK+ development system for Win32, > > cross-compiling from a Debian Linux system. As I am using Debian, I have > > packages of mingw available (3.2.1.20021201.3-1). > >I've tried it it before (building win32 GTK+ 2.2 on Linux host) >Before includes yesterday night. >The autoconf stuff doesn't exactly work flawless. That is probably because the version of libtool is too old. > > > I have taken the libiconv source from ftp.gnu.org, and ran the configure > > script: > > > > CC=i586-mingw32msvc-gcc > > CFLAGS=-I/home/users/ross/bin/win32/include -mcpu=pentium' > > LDFLAGS=-L/home/users/ross/bin/win32/lib -L/usr/i586-mingw32msvc/lib > > ./configure --disable-static --host=i586-mingw32msvc > > > > This appears to work, it detects that I am cross-compiling, knows I am > > building for Windows, etc. However, when building I get: > > > > >/usr/lib/gcc-lib/i586-mingw32msvc/3.2.1/../../../../i586-mingw32msvc/bin/ld > >: warning: cannot find entry symbol _DllMainCRTStartup@12; defaulting to > > 00401000 /usr/i586-mingw32msvc/lib/libmingw32.a(main.o)(.text+0x7f): > > undefined reference to `WinMain@16' > >Got the same thing. >So I configured with --disable-shared (leaving out the --disable-static) in >order to produce a static archive instead of DLL > >I had to install libiconv and libintl manually, IIRC, because >the build system refused to use i686-pc-mingw32-ranlib/ar/dlltool, >stubbornly >using the tools without target prefix ... Perhaps this is also fixed by a newer libtool, but apparently only the CVS version works properly because libtool hasn't been released yet since MinGW support was fixed. > >I then tried to configure glib 2.2.1 >For some reason, it REALLY needs pkg-config...so I installed a (native) >pkg-config >It then bitched about the "growing stack pointer" test, stating that it was >impossible to test when cross-compiling. >So I edited configure, threw out this test and just set the appropriate >ac_cv_... variable to no > >I had to --disable-shared here too, because glib needs libiconv and libintl >(so if it were built as a DLL it would need libiconv.dll and libintl.dll) I see no reason why a glib DLL can't link to a static libiconv, but probably I'm not familiar enough with glib's build process. > >Make then fails on a number of occasions when .exe files are to be linked; >I >had to link them myself adding -lmingwex to the cmd line. >(I suppose you could configure with LDFLAGS=-lmingwex set) This is fixed in MinGW patched versions of GCC. > >Finally it dies on unresolved symbols looking like __imp_gthread_....... >or something. >Building the gthread lib first and adding it to the cmd line didn't help >me, >and I gave up. > >(In the mean time, I had seen that the gcc option -mms-bitfields is not >present in my compiler...My cross-compiler is built from original gcc 3.2.2 >sources, no extra mingw patches applied, so I figured it would never work >after all) The patches are on the MinGW files page in gcc-3.2.2-20030308-1-src.diff.gz (see the "release candidates" section), as is the full MinGW GCC 3.2.2 source. > > > > > Can this be solved? How much do I have to hack, or would I end up > > manually writing Makefiles? > >I would say it needs quite a lot of hacks and that it really does not work >out >of the box (as I hope it will do in "the future") > >And the fact that it is a lot easier to find the pre-built binaries (DLLs >and >import libs) than to find the detailed and exact build instructions as to >how >to get to these DLLs from the sources (as you are trying to do) only seems >to >confirm this thesis. Yes would be easier, for example libiconv source and binaries are available from the MinGW files page in the snapshot section. If you can't bear to use binaries why not try the updated libiconv source from the MinGW page? (I think the updated libtool is the only major change) > >In short: try the prebuilt binaries (I haven't tried them yet; I'm not even >sure whether or not I can use them, not having a patched mingw compiler) I don't know if any of the MinGW GCC patches could cause binary incompatibility, so perhaps someone else can help you there. Actually I think there could be problems with returning <8 byte structures... > >If you find out how to build the stuff from source, don't be afraid to post >detailed build instructions or, even more interesting, send out the >required >configure.ac patches to the respective packages' authors. ;-) > > >Pieter I don't believe any MinGW ports of libiconv have been submitted to the libiconv maintainers so it would be good if someone did so. Luke _________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp |