MinGW link against an MS Windows import library
I could not find any recent discussion of this topic in the list archives. I am trying to use libtool to create a DLL which requires linking my objects against a non-libtool MS Windows import library provided by a 3rd party vendor. The import library has the ".lib" extension and is in a separate directory from the DLL (with ".dll" extension). I am using MinGW 3.1.0, Msys 1.0.9, Msys-DTK 1.0.1 (upgraded to automake-1.8.2, autoconf-2.59, and libtool-1.5.2). Assuming that $import_lib_path is the location of the *.lib file and $import_root_name is the root name of the library (i.e. "foo" for "libfoo.lib"), I have tried adding the following to la_LIBADD in Makefile.am: 1) "-L$import_lib_path -l$import_root_name" results in "ld.exe cannot find -lfoo" 2) "$import_lib_path/lib$import_root_name.lib" is treated as an argument not a library, ignored by libtool as it is not passed to the generated gcc command. However, issuing the gcc command manually works. I think this is because the $lib_ext is set to "a" in the libtool script so this is processed as an argument. 3) Against my better judgement, I tried to alter $libext in my libtool script setting it to "lib". This, however, again dropped the import library argument as libtool viewed the file as a static lib and issued *** Warning: Trying to link with static lib archive $import_lib_path/lib$import_root_name.lib. *** 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 the file extensions .lib of this argument makes me believe *** that it is just a static archive that I should not used here. 4) Specify path to DLL as $import_lib_path will link but generates an unusable libfoo.dll (no supprise here?). I have also tried to use the depreicated AC_LIBTOOL_WIN32_DLL in my configure.in with no differences. So the basic question is how do I specify a static import library with a *.lib extension to be used by libtool for resolving the symbols provided by a non-libtool DLL when building a dependent DLL with libtool? Any help would be appreciated even if I am doing something totally stupid, wtj -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW link against an MS Windows import library
Thanks, but I tried this without success as noted in attempt 4) in my original post. It is my understanding that you should not link directly against a Windows .dll file, but instead link against the import library (.lib). In any event, "-Lpath -lfoo" does produce my DLL when path was set to the path of the .dll file but it was not loadable. I should probably add that my DLL loader functions correctly for similar libtool modules I build that do not require linking against any 3rd party .lib files. wtj Earnie Boyd wrote: Tim Van Holder wrote: Bill Jones wrote: So the basic question is how do I specify a static import library with a *.lib extension to be used by libtool for resolving the symbols provided by a non-libtool DLL when building a dependent DLL with libtool? The trivial solution is of course to make a copy of the third-party .lib file with a .a extension (the file format is identical anyway). Alternatively, you may be able to create a fresh .a from the DLL using 'dllwrap --implib -o ', but it's likely that that won't have all the necessary symbols. Or just use the dll itself in the link. Note if the library references C++ objects, then you are going to be hard pressed for an easy solution. See www.mingw.org and it's list archives for more information. Earnie -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW link against an MS Windows import library
I have considered this but do not see it as a practical solution. I do not think that it should be the responsibility of every developer to make a copy of a file simply because the extension is not what libtool likes. The .lib extension is a valid extension to Windows and it seems more appropriate to have libtool conform to that spec under Windows (MinGW/Cygwin in particular) as I am sure that this will occur frequently. Thanks for the response. wtj Tim Van Holder wrote: Bill Jones wrote: So the basic question is how do I specify a static import library with a *.lib extension to be used by libtool for resolving the symbols provided by a non-libtool DLL when building a dependent DLL with libtool? The trivial solution is of course to make a copy of the third-party .lib file with a .a extension (the file format is identical anyway). Alternatively, you may be able to create a fresh .a from the DLL using 'dllwrap --implib -o ', but it's likely that that won't have all the necessary symbols. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW link against an MS Windows import library
I don't think that linking directly against a DLL under Windows is a good idea (or even possible). From http://blogs.msdn.com/oldnewthing/archive/2004/01/12/57833.aspx it would appear that the LIB file should be used to account for any "decorations" added to the exports. wtj Earnie Boyd wrote: Tim Van Holder wrote: Bill Jones wrote: So the basic question is how do I specify a static import library with a *.lib extension to be used by libtool for resolving the symbols provided by a non-libtool DLL when building a dependent DLL with libtool? The trivial solution is of course to make a copy of the third-party .lib file with a .a extension (the file format is identical anyway). Alternatively, you may be able to create a fresh .a from the DLL using 'dllwrap --implib -o ', but it's likely that that won't have all the necessary symbols. Or just use the dll itself in the link. Note if the library references C++ objects, then you are going to be hard pressed for an easy solution. See www.mingw.org and it's list archives for more information. Earnie -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Building a DLL with libltdl support
I am trying to build a DLL which uses libltdl for dynamic loading of other libtool modules. As a result I am first building libltdl as a "convenience library" using ... AC_LIBLTDL_CONVENIENCE AC_SUBST(INCLTDL) AC_SUBST(LIBLTDL) AC_LIBTOOL_DLOPEN AC_PROG_LIBTOOL AC_CONFIG_SUBDIRS(libltdl) ... in my configure.ac. My DLL is then built with INCLUDES = @INCLTDL@ lib_LTLIBRARIES = libname.la libname_la_SOURCES = ... libname_la_LDFLAGS = -no-undefined -avoid-version libname_la_LIBADD = @LIBLTDL@ All builds without error, however, on Windows under MinGW 3.1.0 and Msys 1.0.9 using automake 1.82. autoconf 2.59 libtool 1.5.2 the resulting export library "libname.dll.a" does not contain any exported symbols other than those provided by libltdl (ex: lt_dlsym...lt_dladderror). The libtool link and resulting gcc commands presented by the `make` are paraphased below: /bin/sh libtool --mode=link gcc -g -O2 -o libname.la -rpath ... -no-undefined -avoid-version file.lo libltdl/libltdlc.la gcc -shared .libs/file.o -Wl,--whole-archive libltdl/.libs/libltdlc.a -Wl,--no-whole-archive -o .libs/libname.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libname.dll.a Again, the library is created, there just aren't any exported symbols from file.o. However, if I instead manually link without the "--whole-archive" of the convenience library and simply use the ltdl object file gcc -shared .libs/file.o libltdl/ltdl.o -o .libs/libname.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libname.dll.a The import library libname.dll.a contains the symbols for libltdl as well as those of file.o as expected. Any help as to what I am doing wrong is greatly appreciated. wtj -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Building a DLL with libltdl support
Under Windows, if any object module has used "__declspec(dllexport)" then this suppresses the default behavior of ld to export all symbols and it only exports those with the above attribute. This is the case with libltdl. The libltdl/ltdl.h header defines "LT_SCOPE" and uses it throughout libltdl. Therefore, you must use the LT_SCOPE macro for any symbols in file.c that need also to be exported. An alternative is to simply pass "--export-all-symbols" to GNU ld assuming that all symbols need export. wtj Bill Jones wrote: I am trying to build a DLL which uses libltdl for dynamic loading of other libtool modules. As a result I am first building libltdl as a "convenience library" using ... AC_LIBLTDL_CONVENIENCE AC_SUBST(INCLTDL) AC_SUBST(LIBLTDL) AC_LIBTOOL_DLOPEN AC_PROG_LIBTOOL AC_CONFIG_SUBDIRS(libltdl) ... in my configure.ac. My DLL is then built with INCLUDES = @INCLTDL@ lib_LTLIBRARIES = libname.la libname_la_SOURCES = ... libname_la_LDFLAGS = -no-undefined -avoid-version libname_la_LIBADD = @LIBLTDL@ All builds without error, however, on Windows under MinGW 3.1.0 and Msys 1.0.9 using automake 1.82. autoconf 2.59 libtool 1.5.2 the resulting export library "libname.dll.a" does not contain any exported symbols other than those provided by libltdl (ex: lt_dlsym...lt_dladderror). The libtool link and resulting gcc commands presented by the `make` are paraphased below: /bin/sh libtool --mode=link gcc -g -O2 -o libname.la -rpath ... -no-undefined -avoid-version file.lo libltdl/libltdlc.la gcc -shared .libs/file.o -Wl,--whole-archive libltdl/.libs/libltdlc.a -Wl,--no-whole-archive -o .libs/libname.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libname.dll.a Again, the library is created, there just aren't any exported symbols from file.o. However, if I instead manually link without the "--whole-archive" of the convenience library and simply use the ltdl object file gcc -shared .libs/file.o libltdl/ltdl.o -o .libs/libname.dll -Wl,--image-base=0x1000 -Wl,--out-implib,.libs/libname.dll.a The import library libname.dll.a contains the symbols for libltdl as well as those of file.o as expected. Any help as to what I am doing wrong is greatly appreciated. wtj -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Libtool convenience library on x86_64
I am trying to link a shared library against a libtool convenience library on an AMD opteron with libtool 1.5.10, automake 1.9, autoconf 2.59, and gcc-3.2.2 (SuSE Linux). If I use the normal method, that works fine under RedHat on Intel x86 (32 bit) and MinGW, I get the following error when linking my shared library: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC If I explicitly specify the "-fPIC" flag as part of my convenience library CFLAGS and rebuild it, then all links fine. My concern here is if some later compiler does not support "-fPIC". I am counting on libtool to figure this stuff out for me. I have read Daniel Reed's posting to [EMAIL PROTECTED] entitled "disable nopic on x86_64 and s390* (was: Re: GNU Libtool 1.5.8 released.)" and it looks like you simply turned off this test. Is this to be actually fixed at some point? Is there a work around for using libtool convenience libraries in building shared libtool libraries? Any help would be appreciated, wtj -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Bill Jones [EMAIL PROTECTED] Mail Stop 125 Data Analysis and Imaging Branch 15 Langley Boulevard Systems Engineering Competency NASA Langley Research CenterBuilding 1268, Room 1038 Hampton, VA 23681-2199Phone +1 757 864-5318 Fax +1 757 864-7635 http://geolab.larc.nasa.gov ___ http://lists.gnu.org/mailman/listinfo/libtool
