Earnie Boyd <[EMAIL PROTECTED]> writes: > Not, totally, but it's being worked upon. I've joined the libtool list > as well in order to help with resolving the issues with mingw32 > host/build/target issues. Hopefully, others that have been actively > working with mingw32 libtool issues can speak to this issue. > > What is your current problem in detail? I.E.: What is failing?
I'd like to automate libxml2's build for a mingw system but it's failing when it tries to build the actual library: /bin/sh ./libtool --mode=link i586-mingw32msvc-gcc -g -O2 -Wall -o libxml2.la -rpath /usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo xmlmemory.lo uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo xpointer.lo xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo threads.lo c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo -lm -lwsock32 rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.* *** Warning: linker path does not have real file for library -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libm but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lwsock32. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libwsock32 but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. i586-mingw32msvc-ar cru .libs/libxml2.a SAX.o entities.o encoding.o error.o parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o xmlschemastypes.o xmlunicode.o i586-mingw32msvc-ranlib .libs/libxml2.a creating libxml2.la (etc... the static library) It went further without the -lm and -lwsock32 but there were many unresolved symbols. I was wondering if libwsock32 was a normal archive but the output of strings suggests it is an import library: (...) _GetAddressByNameA@40 __imp__GetAddressByNameA@40 _GetAcceptExSockaddrs@32 __imp__GetAcceptExSockaddrs@32 _EnumProtocolsW@12 __imp__EnumProtocolsW@12 _EnumProtocolsA@12 __imp__EnumProtocolsA@12 _AcceptEx@32 __imp__AcceptEx@32 dt.o/ 1007767756 0 0 100664 539 ` .text `.data .bss .idata$4 .idata$5 .idata$7 WSOCK32.DLL .text .data .bss .idata$4 .idata$5 .idata$7 __libwsock32_a_iname dh.o/ 1007767756 0 0 100664 651 ` (...) lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a libwsock32.a: current ar archive So I was just wondering about it if the new patches figure out that the stub libraries are not really static. Elizabeth _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool