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

Reply via email to