Elizabeth Barham wrote: > > 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
If course -lm isn't needed for mingw32, there are 3rd party libraries that can be built to provide one though. The easy work-around is to remove the -lm from the list of libraries in the Makefile. The permanent fix would be a rework of the autoconfistification for libxml2 to not include the -lm for target *mingw32*. > 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. > It would need -lwsock32 or -lws2_32 to resolve the unresolved symbols. Static libraries can use shared library 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. > I don't understand the point here. Earnie. _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
