Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?

[Elizabeth Barham]

Earnie Boyd <address@hidden> 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:

(...)
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
address@hidden
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       `
(...)

address@hidden:/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