Linking libstdc++ is broken on Windows

[rl]

Foo.hs:

main = return ()

file.cpp:

#include <iostream>
extern "C" { void foo() { std::cout << "Hello\n"; } }

Building with:

ghc -o tst Foo.hs file.cpp -lstdc++

and then running tst.exe produces this:

tst.exe: error while loading shared libraries: libstdc++-6.dll:
cannot open shared object file: No such file or directory

Adding -optl-static makes the error go away. GHC doesn't seem to ship libstdc++-6.dll but does ship libstdc++-6.dll.a which might cause the problem.

[rl]

Simply removing libstdc++-6.dll.a from the mingw directory fixes this.

[igloo]

We could ship libstdc++-6.dll as well (from libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma), but the executable wouldn't be able to find it, would it?

Are you sure removing libstdc++-6.dll.a really works properly? Neither doing that, nor using -optl-static, is enough to get "Hello" printed for me.

[rl]

Oh, the program isn't supposed to print anything, the reference to std::cout is just there to use something from libstdc++. It's just a question of whether it runs at all or not. Sorry for the confusion. Removing libstdc++.dll.a is sufficient for me. Note that there are actually two of those, one in mingw/lib/gcc/mingw32/4.5.0 and one in mingw/lib/gcc/mingw32/4.5.0/debug. I suppose both ought to be removed.

Shipping the dll doesn't seem like a good idea for the reasons you stated.

The mingw directory also contains libgomp.dll.a and libssp.dll.a but not the corresponding dlls. Perhaps those should be removed as well.

[rl]

We would really appreciate it if this was fixed for 7.0.1. It is really just a question of removing two files from the mingw distribution.

[igloo]

Removing libstdc++.dll.a sounds like the wrong thing to me.

There's no technical reason why we need to include the C++ support at all, but we do so to make it easier for Windows people who want to link with C++ code. I think there are two options that make sense:

* Add libstdc++-6.dll so dynamically linked C++ programs work, although presumably you'll have to either change your path or put the DLL in the right place. If you want a statically linked program then you need to use -optl-static as normal.

* Remove the C++ bits that we currently do include. Users who want C++ support will need install more mingw bits themselves, either as part of the GHC in-tree mingw, or as part of a normal system mingw installation.

Any thoughts?

[rl]

Adding the DLL would be strange. The C libraries (libgcc, libm etc.) aren't shipped as DLLs, why should C++ be treated differently? Either all those DLLs should be included or none of them should.

Removing C++ support doesn't seems like a useful change to me. It's very easy to include in the distribution but rather hard to install separately. Besides, this would be a significant change from 6.12.

[igloo]

Currently our mingw directory is a set of mingw/msys "packages" (and it's now in the same hierarchy as a normal installation, so you can add more packages to it by untarring the tarballs in that directory). Including just part of a package sounds to me like a step in the wrong direction.

[rl]

Oh, I didn't realise that it's a mingw problem, I thought GHC was just including the wrong files. Sorry about the confusion. I suppose the right thing to do would be to include the DLL packages then. I don't really understand, though, why this problem affects libstdc++ but not libgcc. The mingw distribution looks somewhat broken to me.

FWIW, the  mingw site says:

Optionally you may want to add any of the following additional languages; (for each which you choose to install, you need both the bin and the dll component packages)

[igloo]

OK, I've added the DLL in HEAD and the 7.0 branch.