Travis CI fails on Haddock

[roelvandijk]

After fixing #104 we get a lot further through the Travis CI build. But it still fails.

See https://travis-ci.org/LumiGuide/haskell-opencv/builds/331686385#L1603:

      Missing documentation for:
        Module header
        mkRectType (src/OpenCV/Internal/Core/Types/Rect/TH.hs:30)
    haddock: panic! (the 'impossible' happened)
      (GHC version 8.2.2 for x86_64-unknown-linux):
    	Loading temp shared object failed: /tmp/ghc11011_0/libghc_252.so: undefined symbol: __gxx_personality_v0
    
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[basvandijk]

The following might or might not be related:

$ ghc --make ./Setup.hs
...
$ ./Setup haddock
...
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C
...

I'm trying to force haddock to tell GHC to use the C++ compiler but the following produces the same warning:

./Setup haddock --haddock-options="--optghc=-pgmc=c++ --optghc=-pgml=c++"

[basvandijk]

I'm trying to do the same thing as above but using a custom Setup.hs. No luck so far...

[roelvandijk]

I also get these warnings during normal compilation (not Haddock) using nix.

cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C

So this is likely not related to Haddock not passing the appriopriate options to GHC.

[davetapley]

Ah, I feared this would come up (it was prophesied here).
It's been reported haskell/cabal#3700 and fixed haskell/cabal#4810.

Word is it won't be until cabal-2.2 (see here) 😑

[roelvandijk]

Running ghc with -v3 -keep-tmp-files -tmpdir=foo produced some new insights.

All .cpp files are compiled with -x c++.
And two .c files (the only 2) are compiled with -x c.
But all invocations of the C compiler are supplied with the -std=c++11 flag. Which is indeed not valid for C, thus generating the warning.

The two C files contain double Z encoded references to the HighGui module.

zDecodeString $ zDecodeString "zdopencvzm0zi0zi2zi1zmGPqmEeOdChtBw6r6pPytIlzdOpenCVziHighGuizdopencvzzm0zzi0zzi2zzi1zzmGPqmEeOdChtBw6r6pPytIlzuOpenCVzziHighGuizuinlinezzuczzuffizzu6989586621679664641"
"$opencv-0.0.2.1-GPqmEeOdChtBw6r6pPytIl$OpenCV.HighGui$opencv-0.0.2.1-GPqmEeOdChtBw6r6pPytIl_OpenCV.HighGui_inline_c_ffi_6989586621679664641"

They are generated because of the makeWindow function. That function uses newCString internally. That seems to trigger the generation of the .c files. Removing the newCString also got rid of the two .c files. The withCString which is also used in the same function doesn't generate these .c files. Probably because of a different memory management strategy.

I don't know if this is in any way related to Haddock crashing when invoked on Travis CI.

[davetapley]

These should be fixed when haskell/cabal#5075 goes out:

cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C

---

@roelvandijk did you try building without HighGui?

[davetapley]

haskell/cabal#3700 fix went out in Cabal-2.2.0.0 which was released in March.

Unfortunately I've completely forgotten if/how I could repro this locally.

[davetapley]

Ah, after a bit more digging, we're now waiting on this: commercialhaskell/stack#3954

Once that's out we should be able to revert 8029834, and use the new cxx-options with -std=c++11. Hopefully that will keep #104 resolved and eliminate the cc1: warning.

[davetapley]

Good news: Progress being made with commercialhaskell/stack#3954

Bad news: As identified here, cxx-options, requires cabal-version: 2.2., which in turn requires ghc-8.4.1. I think(?) we're okay with GHC 8.4, but unfortunately inline-c, which we depend on, is not: fpco/inline-c#66

---

I identified this by updating the .cabal files to specify cabal-version: 2.2 and stack.yaml to specify resolver: nightly-2018-04-19 (to get GHC 8.4). When I do that it fails:

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for opencv-0.0.2.1:
    inline-c must match >=0.6, but the stack configuration has no specified version (latest matching version is 0.6.0.5)
    inline-c-cpp must match >=0.2.1, but the stack configuration has no specified version (latest matching version is 0.2.1.0)
needed since opencv is a build target.

In the dependencies for opencv-extra-0.2.0.1:
    inline-c must match >=0.6, but the stack configuration has no specified version (latest matching version is 0.6.0.5)
    inline-c-cpp must match >=0.2.1, but the stack configuration has no specified version (latest matching version is 0.2.1.0)
needed since opencv-extra is a build target.

Some potential ways to resolve this:

  * Recommended action: try adding the following to your extra-deps in /home/dave/dev/haskell-opencv/stack.yaml:

- inline-c-0.6.0.5
- inline-c-cpp-0.2.1.0

---

It looks like once fpco/inline-c#66 is merged in then we'll just have to get inline-c back in to the Stackage Nightly Snapshots. I presume it's not in there present due to fpco/inline-c#66.

To do that we'll need to submit a PR re-enabling it by reverting this:
https://github.com/fpco/stackage/blob/1165bfc17bd744a6bc46a311c47bfeec20536722/build-constraints.yaml#L2264

[davetapley]

fpco/inline-c#66 was fixed, and released in 0.6.0.6 🎉

I've made the PR to get it in to the stackage nightly: commercialhaskell/stackage#3578

[basvandijk]

I'm now trying to switch to Cabal-2.2 so that we can use the new cxx-options field. I'm currently blocked on getting the package to build using nix-build. However, we could alreay try if building via travis using the latest LTS or nightly snapshot now succeeds.

[basvandijk]

BTW we're blocked on #116.

[basvandijk]

Since #116 is fixed now I started upgrading the stackage resolver to nightly-2018-05-23 on the cabal-2.2 branch. Unfortunately the travis build fails on:

https://travis-ci.org/LumiGuide/haskell-opencv/builds/382581629#L2462

Any ideas how to fix this one?

[basvandijk]

I see that stack is passing -std=gnu99 to the c++ compiler but I guess it should pass -std=c++11. So it looks like it's not taking the cxx-options into account. Maybe we need a newer stack version...

[basvandijk]

At ZuriHac I was finally able to fix the travis build.