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
> 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.
'-lm' does not exist on win32, however some autoconf macros add it
to $LIBS automatically. I use an extra configure.ac line to
remove these when the target is win32.
'-wsock32' is a problem - I know that some editions have a dll
being named slightly different (-lws32??). On the other hand,
I might wonder what the real sys_lib_search_path_spec does
look like - can have a look into the (builddir) "libtool"
file? That might give a clue... -- guido
btw, what libtool version was that again?
>
> 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
>
>
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
