Thank you for the fast answer. > With the attached patch, it will be included (along with other DLLs), but > in the wrong path. Could you confirm moving it to > /usr/lib/gcc/i586-mingw32msvc/4.4.0/ works for you?
Sorry, with the patch the only "dll" that gets into the package is $dpkg -c ../gcc-mingw32_4.4.0-2_amd64.deb | grep dll -rw-r--r-- root/root 8114 2009-07-29 13:13 ./usr/lib/gcc/i586-mingw32msvc/4.4.0/libssp.dll.a I think this is happening because libgcc_s_sjlj-1.dll is only found in /build-tree/gcc-4.4.0/i586-mingw32msvc/libgcc/shlib/ and not under debian/gcc-mingw32 after the build. I don't know why is not being installed into the later. Reading the release notes I have found that one can use the switch "-static-libgcc" at linking stage in order to get rid of that dependency "for all languages other than C". I have tested this with a C++ example and it works. Unfortunately, one of the biggest improvements of this mingw version is that now there is a new dwarf-based system (instead of the older sjlj one) which is able to throw C++ exceptions between DLL and EXE boundaries. To use it, one has to use --disable-sjlj-exceptions, so a libgcc_s_dw2-1.dll is created instead. The user has to compile the libraries and programs without "-static-libgcc" for the C++ exception system to work between those modules. So I think either the package provides sjlj or dwarf exception systems, it should be good for the user to have a copy of any of those DLLs. I think the specific path doesn't matter since they are not used explicitly at linking time, and the user can always copy them where needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org