libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Guido Draheim
Subject: Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?
Date: Tue, 24 Sep 2002 20:42:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826


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 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:

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


_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool







reply via email to

[Prev in Thread] Current Thread [Next in Thread]