Wolfgang Jeltsch wrote: > I've written a C program which uses libiconv and wanted it to > build on Windows XP using MinGW 5.0.0. For both libiconv and > libintl, I've downloaded the “binaries” and the “developer files” > ZIP archives. I unpacked all four ZIP archives into one common > directory C:\Programme\GNUWin32. > > I run the MinGW GCC with options -I C:\Programme\GNUWin32\include, > -L C:\Programme\GNUWin32\lib, -liconv and -lintl. Alas, I still > get the following messages: > > C:\DOKUME~1\leo\LOKALE~1\Temp/ccINbaaa.o(.text+0xb1):darcs.utf8.c: > undefined reference to `_imp__libiconv_open' > C:\DOKUME~1\leo\LOKALE~1\Temp/ccINbaaa.o(.text+0xf5):darcs.utf8.c: > undefined reference to `_imp__libiconv' > C:\DOKUME~1\leo\LOKALE~1\Temp/ccINbaaa.o(.text+0x102):darcs.utf8.c: > undefined reference to `_imp__libiconv_close' > collect2: ld returned 1 exit status
I've successfully deployed applications, built with MinGW, and using libiconv-1.10, built directly within MSYS from the mingwPORT: http://prdownloads.sourceforge.net/mingw/libiconv-1.10-mingwPORT.tar.bz2?download Your setup is unfamiliar to me, since I use the libs provided, and supported, by the MinGW Project, rather than the GnuWin32 alternatives; however, I see nothing obvious in the above, which might explain why your setup isn't working. FYI, here's how the mingwPORT sets up the libiconv components: $ find /mingw /usr/local -iname '*iconv*' /mingw/include/iconv.h /mingw/lib/libiconv.a /mingw/lib/libiconv.dll.a /usr/local/bin/libiconv-2.dll /usr/local/bin/libiconv2.dll /usr/local/share/doc/libiconv (one of those DLLs is provided by the mingwPORT, the other is a GnuWin32 binary, which is used by other GnuWin32 tools I have; I can't remember which is which -- shame about the discrepancy in the names, otherwise one *might* serve for all). Do note that it's only the static libiconv.a, and the import lib, libiconv.dll.a that go in MinGW's library search path; the DLLs are kept separate, in the runtime PATH. That way, all DLL symbols are resolved through the import lib. If MinGW finds the DLL itself, it will attempt to link to it directly, and ignore the import lib, which may specify required symbol name fixups; as a wild guess, this may be the cause of your problem. > I also tried to mention the file libiconv.a directly on the command > line as an archive file to link with which gave the same result as > above. Which would, naturally, just achieve the same result. > I tried using -llibiconv in addition to -liconv which made no > difference, too. IIRC, that would cause MinGW's GCC to search for: libiconv.dll liblibiconv.dll.a liblibiconv.a libiconv.lib (in this order, I think), which is unlikely to be what you want. HTH, Keith. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ GnuWin32-Users mailing list GnuWin32-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
