Stack build: Windows 7 stdc++.dll missing

[themoritz]

Apparently, stdc++.dll is missing.

Stack build gives the following error message on Windows 7:

PS C:\Users\Moritz\Desktop\metrix\core> ..\stack.exe build
core-0.1.0.0: build
Building core-0.1.0.0...
Preprocessing executable 'core-server' for core-0.1.0.0...
[ 2 of 28] Compiling DPM.Model        ( src\DPM\Model.hs, .stack-work\dist\i386-windows\Cabal-1.22.4.0\build\core-server\core-server-tmp\DPM\Model.o )
<command line>: can't load .so/.DLL for: stdc++.dll (addDLL: could not load DLL)
ghc.exe: stdc++: The specified module could not be found.

--  While building package core-0.1.0.0 using:
      C:\\Users\\Moritz\\AppData\\Local\\Programs\\stack\\i386-windows\\ghc-7.10.2\\bin\\runhaskell.exe -package=Cabal-1.22.4.0 -clear-package-db -global-package-db -package-db=C:\Users\Moritz\AppData\Roaming\stack\snapshots\i386-windows\ni
ghtly-2015-06-17\7.10.2\pkgdb\ C:\Users\Moritz\AppData\Local\Temp\stack2096\Setup.hs --builddir=.stack-work\dist\i386-windows\Cabal-1.22.4.0\ build
    Process exited with code: ExitFailure 1

Here are the imports of the DPM.Model module:

module DPM.Model where

import           Data.Text           (Text)
import           Database.Persist.TH (mkPersist, persistUpperCase,
                                      share, sqlSettings)
import Data.Int (Int64)
import Data.Time (UTCTime)

[snoyberg]

I've never been successful at getting C++ libraries working on Windows. This far predates stack for me, and even came up on the issue tracker previously regarding the formatting library:

#300

If anyone has input on how to solve this, that would be great, but I have no plans on it right now.

[rubenmoor]

Given that it's probably easiest to avoid the dependency on double-conversion for the time being. Now I have the task to find the package that causes that dependency ...

[snoyberg]

stack dot --external may be of some use there :)

[rubenmoor]

Indeed, thanks!

[themoritz]

I don't know if this is of any help but copying mingw/bin/libstdc++-6.dll to ghc/bin/stdc++.dll gives

ghc.exe: unable to load package `double-conversion-2.0.1.0`
ghc.exe: C\:Users\.....\double-conversion-2.0.1.0-....-.....o: unknown symbol `__Unwind_Resume`

[lukexi]

I think that error can be fixed by linking libgcc_s_sjlj-1.dll which should come with mingw; you might see some other weirdness after that if you're using Template Haskell:
https://ghc.haskell.org/trac/ghc/ticket/10672

I'm super keen to get this figured out once and for all — I've been battling with it myself trying to link bindings to the Bullet Physics library on Windows. For the stuff I'm doing (3D/VR engine development) C++ bindings are totally essential!

[snoyberg]

Closing; if someone wants to send some documentation PRs to help with the situation, that will definitely be appreciated!

[Mistuke]

Hello,

GHC issue #10672 is now fixed, once GHC #10955 is finished and committed this should be solved.
Pull request has been submitted to fix double-conversion.

haskell/double-conversion#13

[snoyberg]

Thanks!

On Sat, Oct 10, 2015, 6:55 PM Tamar Christina notifications@github.com
wrote:

Hello,

GHC issue #10672 is now fixed, once GHC #10955 is finished and committed
this should be solved.
Pull request has been submitted to fix double-conversion.

haskell/double-conversion#13
haskell/double-conversion#13

—
Reply to this email directly or view it on GitHub
#754 (comment)
.

[quyse]

I have a workaround to allow usage of Template Haskell with C++ on Windows.

First, create file all.def like this:

EXPORTS
    __mingw_vsprintf
    __mingw_vsnprintf
    strdup
    __popcountdi2
    snprintf
    mingw_getsp
    _Unwind_Resume

Execute: stack exec gcc -- all.def -shared -oall.dll, and put resulting all.dll into mingw/lib path.
Add extra-ghci-libraries: all to .cabal file of package which links C++. Try to compile your stuff - now it should be built smoothly. If ghc complains again about missing symbol, add it to all.def too and repeat the process. And if gcc cannot compile all.dll because of unknown symbol, remove it from all.def (apparently list of symbols needed depends on ghc/gcc/mingw versions).

Note you don't need to rename libstdc++-6.dll. At least for me this trick alone fixes everything and allows me to link with C++ and use Template Haskell. It also doesn't add all.dll runtime dependency to resulting executable, as it's only for TH/ghci, i.e. needed only during compilation.

I was hoping this is fixed in GHC 7.10.3, as multiple related tickets have been closed, like GHC 3242. But as I can see from practice, it's not fixed in 7.10.3. Looks like the actual tickets now are GHC 10726, GHC 11223.

It's actually very annoying, would be great to see some temporary workaround wired-in into stack, until it's not fixed in ghc. BTW I think I was able to add this extra-ghci-libraries line into global cabal config, and it was working for all packages I build with cabal, but can I do such a thing with stack?

ADDITION: this method works for me with GHC 7.10.3.