On Wed, Jul 29, 2009 at 04:19:14PM +0200, Alberto Luaces wrote: > 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.
Now that I check, the mingw32 package doesn't include any DLL either, only static objects like libgcc.a. Why is this not an issue there? > 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. Can you provide a test case? > 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. Switching to Dwarf exception handling changes ABI, so if we do this it needs to be coordinated with mingw32 maintainer (CCed). -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
