On 19/05/14 23:36, Stephen Kitt wrote:
Hi Eugen,On Mon, 19 May 2014 19:28:53 +0200, Eugen Dedu <eugen.d...@pu-pm.univ-fcomte.fr> wrote:Thank you for maintaining mingw-w64 for debian!It's always a pleasure!I try to compile ekiga using mingw-w64 and the problem is that it generates only a .a, not a .dll. The reason is that libtool gives errors like this:[...]The problem is with the ones recognised as archive static. The following files have this problem in my case: libdxerr9.a, libdxguid.a, libstrmiids.a, libuuid.a. Do you know why the above files have this problem? Feel free to ask me more information if needed.The archive static files are object archives, built from C files compiled to object files and archived. The archive import files are stubs for DLLs, build from definition files. For example, dsound which you mention is built from mingw-w64-crt/lib32/dsound.def in the mingw-w64 source; whereas uuid is built from a bunch of C source files (see mingw-w64-crt/Makefile.am for details; look for "src_libuuid"). What exactly are you trying to do? I know that it is possible to link both static and import archives into a DLL, wine-gecko does that with libuuid amongst others; looking through my build logs I see i686-w64-mingw32-g++ -mwindows -shared -Wl,--out-implib -Wl,libmozglue.dll.a -o mozglue.dll dummy.o ./module.res -lpthread -static-libgcc -static-libstdc++ -Wl,--enable-stdcall-fixup -Wl,--large-address-aware mozglue.def ../../mfbt/libmfbt.a /tmp/buildd/wine-gecko-2.21-2.21+dfsg1/wine_gecko-2.21-x86/modules/zlib/src/libmozz.a -luuid -lgdi32 -lwinmm -lwsock32 -luserenv -lsecur32 -lnetapi32 (and the resulting mozglue.dll is used later on in the build for other DLLs and so forth).
I made some insight in this issue. I can reproduce on a simple example.
Take a simple main.cpp:
int main (){
return 0;
}
Take a libtool file you created from a mingw build. I tested with one
generated this month, and another one generated one year ago, where the
build worked. Both exhibit the bug, so libtool does not have any
problem, it seems. I attach a libtool in case you need one.
There is no problem when executing:/bin/bash ../libtool --tag=CXX --mode=link i686-w64-mingw32-g++ -shared -module -no-undefined -avoid-version -ldxerr9 -o libekiga.la main.cpp
The bug appears when adding "-rpath /" (or another directory):/bin/bash ../libtool --tag=CXX --mode=link i686-w64-mingw32-g++ -shared -module -no-undefined -avoid-version -ldxerr9 -o libekiga.la -rpath / main.cpp
This command yields: *** Warning: linker path does not have real file for library -ldxerr9. *** 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 libdxerr9 and none of the candidates passed a file format test*** using a file magic. Last file checked: /usr/i686-w64-mingw32/lib/libdxerr9.a
*** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libekiga. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag.If you add -lwinmm for ex., it does not generate the warning. It appears only with some libraries, as described in the initial report of this bug.
-- Eugen
libtool.gz
Description: application/gzip
