From: Elizabeth B. <sog...@ya...> - 2002-09-24 14:50:11
|
Hi, A while back, Bob mentioned running into some trouble linking a dll with the stub lib*.a libraries: <http://mail.gnu.org/pipermail/libtool/2002-June/006401.html> and has contributed some patches to libtool (whether in regards to this I do not know). Anyway, I, too, recently had a similar error as what Bob mentioned in the previous email cited above. So, I am curious as to whether or not the kink has been ironed out. Thank you, Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-24 15:25:58
|
Elizabeth Barham wrote: > > Hi, > > A while back, Bob mentioned running into some trouble linking a dll > with the stub lib*.a libraries: > > <http://mail.gnu.org/pipermail/libtool/2002-June/006401.html> > > and has contributed some patches to libtool (whether in regards to > this I do not know). > > Anyway, I, too, recently had a similar error as what Bob mentioned in > the previous email cited above. > > So, I am curious as to whether or not the kink has been ironed out. > 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? Earnie. |
From: Bob F. <bfr...@si...> - 2002-09-24 15:39:13
|
On Tue, 24 Sep 2002, Earnie Boyd wrote: > Elizabeth Barham wrote: > > > > A while back, Bob mentioned running into some trouble linking a dll > > with the stub lib*.a libraries: > > > > <http://mail.gnu.org/pipermail/libtool/2002-June/006401.html> > > > > and has contributed some patches to libtool (whether in regards to > > this I do not know). > > > > Anyway, I, too, recently had a similar error as what Bob mentioned in > > the previous email cited above. > > > > So, I am curious as to whether or not the kink has been ironed out. This update to CVS libtool resolves most of these problems: 2002-06-26 Bob Friesenhahn <bfr...@si...> * libtool.m4 (AC_LIBTOOL_SYS_DYNAMIC_LINKER) [mingw]: Remove extraneous '=' character which appears in gcc 3.1 -print-search-dirs output. Handle both upper and lower case drive letters when testing for Windows vs POSIX style path output from -print-search-dirs output. The problem is that some directories searched by the compiler were being ignored by libtool due to the two listed problems (particularly the second one, which caused the MinGW libs to be ignored). Using CVS libtool I am able to build static libraries against a set of DLLs, but there are failures if --enable-shared is added to the configure arguments. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Elizabeth B. <sog...@ya...> - 2002-09-26 04:35:30
|
This is just a simple report-in about the errors I mentioned having yesterday or the day before. The latest CVS libtool did not have any trouble and made the DLL fine. I'd also like to mention that the whole libtool seemed to work quicker than before. Thank you all very much and great job! On a related note, I have been having to add a "main" function to the DLL's like so: #if defined(__MINGW32__) && defined(DLL_EXPORT) int main(int argc, char* argv[]) { return 0; } #endif If I do not add this, it does not build the DLL. I'm concerned about the export of this function, however - if more than one DLL uses this method, could there be some kind of conflict and/or is there a better way to deal with this? Thank you, Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-26 11:07:28
|
Elizabeth Barham wrote: > > This is just a simple report-in about the errors I mentioned having > yesterday or the day before. The latest CVS libtool did not have any > trouble and made the DLL fine. > > I'd also like to mention that the whole libtool seemed to work quicker > than before. > > Thank you all very much and great job! > > On a related note, I have been having to add a "main" function to the > DLL's like so: > > #if defined(__MINGW32__) && defined(DLL_EXPORT) > int > main(int argc, char* argv[]) > { > return 0; > } > #endif > You shouldn't do this. I posted on the libtool list a mingwlibsample.tar.gz under the heading of "Simple dll and static library creation for MinGW" dated 9/19/2002. > If I do not add this, it does not build the DLL. I'm concerned about > the export of this function, however - if more than one DLL uses this > method, could there be some kind of conflict and/or is there a better > way to deal with this? > The -shared switch is required to build the dll. Earnie. |
From: Elizabeth B. <sog...@ya...> - 2002-09-26 17:15:12
|
Earnie Boyd <ear...@ya...> writes: > You shouldn't do this. I posted on the libtool list a > mingwlibsample.tar.gz under the heading of "Simple dll and static > library creation for MinGW" dated 9/19/2002. Thank you. If anyone else is interested in this, I placed a copy at: <http://www.soggytrousers.net/repository/mingwlibsample.tar.gz> Elizabeth |
From: Elizabeth B. <sog...@ya...> - 2002-09-27 19:40:18
|
> If anyone else is interested in this, I placed a copy at: > > <http://www.soggytrousers.net/repository/mingwlibsample.tar.gz> Here is an autoconfiscated version with the new libtool: <http://www.soggytrousers.net/repository/hello-0.1.tar.gz> Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-27 20:50:30
|
Elizabeth Barham wrote: > > > If anyone else is interested in this, I placed a copy at: > > > > <http://www.soggytrousers.net/repository/mingwlibsample.tar.gz> > > Here is an autoconfiscated version with the new libtool: > > <http://www.soggytrousers.net/repository/hello-0.1.tar.gz> > Thanks. But, it didn't create any .exe to use the libraries. Earnie. |
From: Earnie B. <ear...@ya...> - 2002-09-27 21:33:47
|
Earnie Boyd wrote: > > Elizabeth Barham wrote: > > > > > If anyone else is interested in this, I placed a copy at: > > > > > > <http://www.soggytrousers.net/repository/mingwlibsample.tar.gz> > > > > Here is an autoconfiscated version with the new libtool: > > > > <http://www.soggytrousers.net/repository/hello-0.1.tar.gz> > > > > Thanks. But, it didn't create any .exe to use the libraries. > I found the reason, and I must say Elizabeth did a nice job. make ;# Create the libraries make check ;# Create binaries that use the libraries. Thanks Elizabeth, Earnie. |
From: Elizabeth B. <sog...@ya...> - 2002-09-27 22:29:31
|
Earnie Boyd <ear...@ya...> writes: > I found the reason, and I must say Elizabeth did a nice job. Thanks, but.... it did not work on my copy of MSYS unfortunately. When building the dll, the -mdll was added onto the command line and gcc errored out saying they were incompatible. Oh well. I am curious about the necessity of passing -no-undefined to the command line and I hesitate to bring this up without a solution, but it seems to me that this is implicitly needed when building a dll. I am wondering if the flag is necessary in the Win32 environment for other uses or if it would do any harm to define it automatically when building a dll in mingw32? Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-28 00:31:28
|
Elizabeth Barham wrote: > > Earnie Boyd <ear...@ya...> writes: > > > I found the reason, and I must say Elizabeth did a nice job. > > Thanks, but.... it did not work on my copy of MSYS unfortunately. When > building the dll, the -mdll was added onto the command line and gcc > errored out saying they were incompatible. Oh well. > Hmm... I didn't get that at all. Make sure you remove /etc/config.site. As for -mdll, it may be useful on the object build. Danny Smith, can you speak to the -mdll switch effect in cc1? The --help gives, "Generate code for a DLL". > I am curious about the necessity of passing -no-undefined to the > command line and I hesitate to bring this up without a solution, but > it seems to me that this is implicitly needed when building a dll. I > am wondering if the flag is necessary in the Win32 environment for > other uses or if it would do any harm to define it automatically when > building a dll in mingw32? > Try the gettext-0.11.5 bundle. You'll see that -no-undefined brings a static only build with libtool. It's used in the libintl build so that the shared library of gettext exports what's needed for it. Currently libtool doesn't like this scenario for win32 dll's but it is possible to do that. Earnie. |
From: Elizabeth B. <sog...@ya...> - 2002-09-28 06:09:18
|
> Here is an autoconfiscated version with the new libtool: > > <http://www.soggytrousers.net/repository/hello-0.1.tar.gz> This one uses a better technique to determine the flag it should use to make the DLL and does not hardcode -shared onto the command line: <http://www.soggytrousers.net/repository/hello-0.2.tar.gz> What is weird is the output of configure... [...] checking dynamic linker characteristics... Win32 ld.exe checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool [...] checking dynamic linker characteristics... Win32 ld.exe appending configuration tag "F77" to libtool checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes But it builds both nonetheless. Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-28 09:04:54
|
Elizabeth Barham wrote: > > > Here is an autoconfiscated version with the new libtool: > > > > <http://www.soggytrousers.net/repository/hello-0.1.tar.gz> > > This one uses a better technique to determine the flag it should use > to make the DLL and does not hardcode -shared onto the command line: > > <http://www.soggytrousers.net/repository/hello-0.2.tar.gz> > > What is weird is the output of configure... > > [...] > > checking dynamic linker characteristics... Win32 ld.exe > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > configure: creating libtool > > [...] > > checking dynamic linker characteristics... Win32 ld.exe > appending configuration tag "F77" to libtool ^^^ The libtool.m4 has different rule sets for each supported compiler. > checking if libtool supports shared libraries... no > checking whether to build shared libraries... no > checking whether to build static libraries... yes > > But it builds both nonetheless. > If you had a F77 version it would only build static. It's poor design for libtool.m4 to check what the user doesn't want. Earnie. |
From: Elizabeth B. <sog...@ya...> - 2002-09-26 21:51:31
|
Earnie Boyd <ear...@ya...> writes: > > On a related note, I have been having to add a "main" function to the > > DLL's like so: > > > > #if defined(__MINGW32__) && defined(DLL_EXPORT) > > int > > main(int argc, char* argv[]) > > { > > return 0; > > } > > #endif > > > > You shouldn't do this. I posted on the libtool list a > mingwlibsample.tar.gz under the heading of "Simple dll and static > library creation for MinGW" dated 9/19/2002. <http://www.soggytrousers.net/repository/mingwlibsample.tar.gz> > > If I do not add this, it does not build the DLL. I'm concerned about > > the export of this function, however - if more than one DLL uses this > > method, could there be some kind of conflict and/or is there a better > > way to deal with this? > > > > The -shared switch is required to build the dll. If anyone is interested in this, libtool made the dll fine without the main function mentioned above by adding -shared after the $CC: --BEGIN-- # Commands used to build and install a shared archive. archive_cmds="" archive_expsym_cmds="if test \\\"x\\\`sed 1q \$export_symbols\\\`\\\" = xEXPORTS; then cp \$export_symbols \$output_objdir/\$soname-def; else echo EXPORTS > \$output_objdir/\$soname-def; _lt_hint=1; cat \$export_symbols | while read symbol; do set dummy \\\$symbol; case \\\$# in 2) echo \\\" \\\$2 @ \\\$_lt_hint ; \\\" >> \$output_objdir/\$soname-def;; 4) echo \\\" \\\$2 \\\$3 \\\$4 ; \\\" >> \$output_objdir/\$soname-def; _lt_hint=\\\`expr \\\$_lt_hint - 1\\\`;; *) echo \\\" \\\$2 @ \\\$_lt_hint \\\$3 ; \\\" >> \$output_objdir/\$soname-def;; esac; _lt_hint=\\\`expr 1 + \\\$_lt_hint\\\`; done; fi~ \$CC -shared -Wl,--base-file,\$output_objdir/\$soname-base -Wl,-e,_DllMainCRTStartup@12 -o \$output_objdir/\$soname \$libobjs \$deplibs \$compiler_flags~ \$DLLTOOL --as=\$AS --dllname \$soname --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12 --def \$output_objdir/\$soname-def --base-file \$output_objdir/\$soname-base --output-exp \$output_objdir/\$soname-exp~ \$CC -shared -Wl,--base-file,\$output_objdir/\$soname-base \$output_objdir/\$soname-exp -Wl,-e,_DllMainCRTStartup@12 -o \$output_objdir/\$soname \$libobjs \$deplibs \$compiler_flags~ \$DLLTOOL --as=\$AS --dllname \$soname --exclude-symbols DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12 --def \$output_objdir/\$soname-def --base-file \$output_objdir/\$soname-base --output-exp \$output_objdir/\$soname-exp --output-lib \$output_objdir/\$libname.dll.a~ \$CC -shared \$output_objdir/\$soname-exp -Wl,-e,_DllMainCRTStartup@12 -o \$output_objdir/\$soname \$libobjs \$deplibs \$compiler_flags" postinstall_cmds="" postuninstall_cmds="" --END-- Note the addition of "-shared" after the \$CC. Similar lines may be found in libtool.m4 v. 1.264 at 4700, 4702 and 4704. Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-09-27 16:22:46
|
Elizabeth Barham wrote: > > Earnie Boyd <ear...@ya...> writes: > > > > > The -shared switch is required to build the dll. > > If anyone is interested in this, libtool made the dll fine without the > main function mentioned above by adding -shared after the $CC: > Ok, submit a proper patch against the CVS source to li...@gn... for proper credit for the fix. Earnie. |
From: Max B. <ma...@uk...> - 2002-09-27 17:49:15
|
Earnie Boyd wrote: > Elizabeth Barham wrote: > > > > Earnie Boyd <ear...@ya...> writes: > > > > > > > > The -shared switch is required to build the dll. > > > > If anyone is interested in this, libtool made the dll fine without the > > main function mentioned above by adding -shared after the $CC: > > > > Ok, submit a proper patch against the CVS source to li...@gn... for > proper credit for the fix. ?!?!? Didn't she just say that it _already_ worked fine? Max. |
From: Elizabeth B. <sog...@ya...> - 2002-09-27 18:24:11
|
"Max Bowsher" <ma...@uk...> writes: > Earnie Boyd wrote: > > Elizabeth Barham wrote: > > > > > > Earnie Boyd <ear...@ya...> writes: > > > > > > > > > > > The -shared switch is required to build the dll. > > > > > > If anyone is interested in this, libtool made the dll fine without the > > > main function mentioned above by adding -shared after the $CC: > > > > > > > Ok, submit a proper patch against the CVS source to li...@gn... for > > proper credit for the fix. > > ?!?!? Didn't she just say that it _already_ worked fine? No, just that by modifying the generated libtool that it worked fine and that certain lines in libtool.m4 are extremely similar (it did not work fine before without a "main" function in the dll). So, what I modified libtool.m4 and tried to use the new builds to make a similar libtool but so far they have not been successful although it is possible that the error is due to my not running "aclocal" after modifying libtool.m4 - which I did a little while ago and libtool is in the "make check" phase at this moment. Provided that the changes are correctly propagated to the generated libtool and the tests correctly work, I shall then submit a patch if there are no objections. Thank you, Elizabeth |
From: Danny S. <dan...@cl...> - 2002-09-28 02:40:04
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: "Elizabeth Barham" <sog...@ya...> Cc: <min...@li...> Sent: Saturday, 28 September 2002 01:31 Subject: Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries? > Elizabeth Barham wrote: > > > > Earnie Boyd <ear...@ya...> writes: > > > > > I found the reason, and I must say Elizabeth did a nice job. > > > > Thanks, but.... it did not work on my copy of MSYS unfortunately. When > > building the dll, the -mdll was added onto the command line and gcc > > errored out saying they were incompatible. Oh well. > > > Hmm... I didn't get that at all. Make sure you remove > /etc/config.site. As for -mdll, it may be useful on the object build. > Danny Smith, can you speak to the -mdll switch effect in cc1? The > --help gives, "Generate code for a DLL". > -mdll doesn't set any internal flags for cc1.exe, nor does -shared. -mdll tells driver to pass dllcrt2.o rather than crt2.o as startup object to ld and to use _DllMainCRTStartup@12 as entry point address. -shared does this too. -mdll passes --dll to ld. -shared passes -shared to ld. This is where the difference is: --dll only says: 'use default image base for dlls'. It doesn't do any of the relocateability magic. -shared says: "build a relocateable dll (or more generally, a shareable library)" ie, do all the things that dllwrap/dlltool would do HTH. Danny |
From: Earnie B. <ear...@ya...> - 2002-09-28 03:56:33
|
Danny Smith wrote: > > -mdll doesn't set any internal flags for cc1.exe, nor does -shared. > > -mdll tells driver to pass dllcrt2.o rather than crt2.o as startup > object to ld > and to use _DllMainCRTStartup@12 as entry point address. -shared does > this too. > > -mdll passes --dll to ld. -shared passes -shared to ld. This is where > the difference is: > > --dll only says: 'use default image base for dlls'. It doesn't do any > of the relocateability magic. > -shared says: "build a relocateable dll (or more generally, a shareable > library)" ie, do all the things that dllwrap/dlltool would do > So the use of -mdll or --dll should not be used by libtool. Only -shared should be used. Earnie. |
From: <dan...@ya...> - 2002-09-28 04:25:02
|
--- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > -mdll doesn't set any internal flags for cc1.exe, nor does -shared. > > > > -mdll tells driver to pass dllcrt2.o rather than crt2.o as startup > > object to ld > > and to use _DllMainCRTStartup@12 as entry point address. -shared does > > this too. > > > > -mdll passes --dll to ld. -shared passes -shared to ld. This is where > > the difference is: > > > > --dll only says: 'use default image base for dlls'. It doesn't do any > > of the relocateability magic. > > -shared says: "build a relocateable dll (or more generally, a shareable > > library)" ie, do all the things that dllwrap/dlltool would do > > > > So the use of -mdll or --dll should not be used by libtool. Only > -shared should be used. > Correct, unless there is a reason to build a non-relocateable library or an .exe that exports symbols, or want a non-default entry point or do other things where you need more control over base files and exp files. Danny > Earnie. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://mobile.yahoo.com.au - Yahoo! Messenger for SMS - Always be connected to your Messenger Friends |
From: Elizabeth B. <sog...@ya...> - 2002-09-24 17:01:40
|
Earnie Boyd <ear...@ya...> 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: (...) _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 |
From: Earnie B. <ear...@ya...> - 2002-09-24 18:27:35
|
Elizabeth Barham wrote: > > Earnie Boyd <ear...@ya...> 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. |
From: Earnie B. <ear...@ya...> - 2002-09-25 01:12:32
|
Hmm..., if libtool.m4 exists in the package, make sure you replace it with a copy from the CVS and execute aclocal again. Earnie. Elizabeth Barham wrote: > > Earnie Boyd <ear...@ya...> 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: > > (...) > _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 > Li...@gn... > http://mail.gnu.org/mailman/listinfo/libtool |
From: Guido D. <gui...@gm...> - 2002-09-24 18:39:48
|
Elizabeth Barham wrote: > Earnie Boyd <ear...@ya...> 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 > Li...@gn... > http://mail.gnu.org/mailman/listinfo/libtool > > |
From: Oscar F. <of...@wa...> - 2002-09-24 19:03:24
|
Guido Draheim <gui...@gm...> writes: > '-lm' does not exist on win32, There is a libm.a on MinGW's lib directory. Seems it is a dummy library for those *nix builds that uses -lm. [snip] -- Oscar |