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

[Earnie Boyd]

Elizabeth Barham wrote:
> 
> 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

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:
> 
> (...)
> 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.
> 

I don't understand the point here.

Earnie.