Error when building some C++ source

davetapley commented 6 years ago

When building with resolver: lts-10.1 in stack.yaml:

  [53 of 71] Compiling OpenCV.ImgProc.StructuralAnalysis ( .stack-work/dist/x86_64-linux/Cabal-2.0.1.0/build/OpenCV/ImgProc/StructuralAnalysis.hs, .stack-work/dist/x86_64-linux/Cabal-2.0.1.0/build/OpenCV/ImgProc/StructuralAnalysis.o )
    /tmp/ghc18962_0/ghc_578.cpp: In function ‘void inline_c_OpenCV_ImgProc_StructuralAnalysis_2(cv::Mat*, int32_t, int32_t, int32_t*, cv::Point2i****, cv::Vec4i***, int32_t**)’:

    /tmp/stack4848/opencv-0.0.2.0//tmp/ghc18962_0/ghc_578.cpp:59:40: error:
         error: ‘>>’ should be ‘> >’ within a nested template argument list
               std::vector<std::vector<cv::Point>> contours;
                                                ^
       |
    59 |       std::vector<std::vector<cv::Point>> contours;
       |                                        ^

    /tmp/stack4848/opencv-0.0.2.0//tmp/ghc18962_0/ghc_578.cpp:83:45: error:
         error: ‘>>’ should be ‘> >’ within a nested template argument list
               for (std::vector<std::vector<cv::Point>>::size_type i = 0; i < contours.size(); i++) {
                                                     ^
       |
    83 |       for (std::vector<std::vector<cv::Point>>::size_type i = 0; i < contours.size(); i++) {
       |                                             ^
    `gcc' failed in phase `C Compiler'. (Exit code: 1)

It's fine with lts-9.10 (as used in your stack.yaml), but thought you might want to know.

davetapley commented 6 years ago

I've isolated this down to breaking between:

inline-c-0.5.6.1 / inline-c-cpp-0.1.0.0 (used in lts-9.10) and inline-c-0.6.0.5 / inline-c-cpp-0.2.1.0 (used in lts-10.1)

For the curious, I was able to downgrade these on my own stack project, whilst staying on lts-10.1 and Stack 1.6.3 by using a custom snapshot, thus:

#  old-inline-c-snapshot.yml
resolver: lts-10.1
name: old-inline-c-snapshot
packages:
  - inline-c-0.5.6.1
  - inline-c-cpp-0.1.0.0

Then updating my stack.yaml to specify:

resolver: "./old-inline-c-snapshot.yaml"

basvandijk commented 6 years ago

@dukedave thanks for the report and the investigation. Can you check if the latest master builds for you?

davetapley commented 6 years ago

@basvandijk I just forked and pulled to test locally, but I've getting the same build errors as Travis. Is that a new failure, or has Travis been neglected for a while?

basvandijk commented 6 years ago

Hi @dukedave, I have seen the errors on travis but I'm not sure yet how to solve them. Do you have any ideas?

davetapley commented 6 years ago

Not yet @basvandijk. I tried reproducing the build using a Stack's Docker integration (I switch between Mac and Ubuntu, so I'd like to have something consistent), but with that I get:

 [57 of 71] Compiling OpenCV.ImgProc.GeometricImgTransform ( .stack-work/dist/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/Cabal-2.0.1.0/build/OpenCV/ImgProc/GeometricImgTransform.hs, .stack-work/dist/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/Cabal-2.0.1.0/build/OpenCV/ImgProc/GeometricImgTransform.o )
    /tmp/ghc181_0/ghc_654.cpp: In function ‘cv::Exception* inline_c_OpenCV_ImgProc_GeometricImgTransform_6(cv::Mat*, cv::Mat*, cv::Mat*, int32_t, int32_t, cv::Scalar*)’:

    /Users/dtapley/dev/haskell-opencv/opencv//tmp/ghc181_0/ghc_654.cpp:140:15: error:
         warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
                     , {}
                       ^
        |
    140 |             , {}
        |               ^

Have you looked in to using Stack with Docker? I may open a new issue / PR to do that.

basvandijk commented 6 years ago

I've reopened the issue because this is not solved yet.

@dukedave I haven't used Stack with Docker. I'm using Nix to get deterministic builds.

basvandijk commented 6 years ago

It's surprising we get an error/warning about a missing -std=c++11 option since we explicitly specify that in the cabal file.

davetapley commented 6 years ago

Okay, I've got the build working* locally both with nix and using Stack's Docker integration. I'll open a separate issue / PR with the Docker stuff.

* I am now seeing the same errors as the latest Travis build, namely those starting with:

    /tmp/ghc16778_0/ghc_41.cpp: In function ‘bool inline_c_OpenCV_Extra_ArUco_4(VectorVectorPoint2f*, VectorInt*, cv::Mat*, Ptr_CharucoBoard*, cv::Mat**, cv::Mat**)’:

    /home/dave/dev/haskell-opencv/opencv-extra//tmp/ghc16778_0/ghc_41.cpp:49:16: error:
         error: ISO C++ forbids declaration of ‘corners’ with no type [-fpermissive]
                 auto & corners = *carucoCorners_27_inline_c_0;
                        ^
       |
    49 |         auto & corners = *carucoCorners_27_inline_c_0;
       |                ^

I am seeing the same error both with and without the Docker integration, so that's something :grinning:

davetapley commented 6 years ago

@basvandijk I agree that these in the build log are the smoking gun for the root of ⬆️ :

cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ [enabled by default]

But, for all my trying, I just can't get it to use -std=c++11 😞

Based on my research, the only things required should be:

Using cc-options, which we do here, and:
Adding extra-libraries: stdc++ which we do here.

This could also be relevant: https://github.com/haskell/cabal/pull/4810, but I'm not sure.

Additionally, I went back to see when the build started failing, and identified this build as the most recent green one. However it appears that the cpp files weren't being found during those builds. I'm not sure why that wasn't causing the build to fail, but it might explain the difference.

Finally: I'd like to open a new issue, since 55d4913c8e183fffa5d25a59083b74404bbd656d did fix my original error, and this does seem to be something different. Cool?

basvandijk commented 6 years ago

Thanks for diving into this tricky problem.

Note there's a third thing that is required:

Passing the --with-gcc c++ --with-ld c++ command line options to the configure phase. Which we do in our custom Setup.hs. Maybe stack doesn't handle that properly...

davetapley commented 6 years ago

Could be @basvandijk. I found that stack has a -v flag for its build command, if and if you turn that on you can see the configure:

[debug] Run process: /Users/dtapley/dev/haskell-opencv/opencv-extra/.stack-work/dist/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/Cabal-2.0.1.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-dk1d9d6f18
b8ece84b04ed64c4bc333808/Cabal-2.0.1.0 configure --with-ghc=/opt/ghc/8.2.2/bin/ghc --with-ghc-pkg=/opt/ghc/8.2.2/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/Users/dtapley/.stack/snapshots/x86_64-linux-dk1d9d6f1
8b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/pkgdb --package-db=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/pkgdb --libdir=/Users/dtapley/dev/haskell-opencv/.stack-work/
install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/lib --bindir=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/bin --datadir=/Users/dtapley/dev/hask
ell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/share --libexecdir=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/libexec
--sysconfdir=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/etc --docdir=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc
333808/lts-10.2/8.2.2/doc/opencv-extra-0.2.0.1 --htmldir=/Users/dtapley/dev/haskell-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/doc/opencv-extra-0.2.0.1 --haddockdir=/Users/dtapley/dev/haskell
-opencv/.stack-work/install/x86_64-linux-dk1d9d6f18b8ece84b04ed64c4bc333808/lts-10.2/8.2.2/doc/opencv-extra-0.2.0.1 --dependency=Cabal=Cabal-2.0.1.1-K7BBuT85dPfIf5Y1YG7kmd --dependency=base=base-4.10.1.0 --dependency=bindings-DSL=bindings
-DSL-1.0.24-F6yWEmrQkde519p3ekzWvj --dependency=bytestring=bytestring-0.10.8.2 --dependency=containers=containers-0.5.10.2 --dependency=inline-c=inline-c-0.6.0.5-IiDfXcENHv57AiwCo2cDsE --dependency=inline-c-cpp=inline-c-cpp-0.2.1.0-14X5pM
teOFQ1sUTw8rK5Bq --dependency=linear=linear-1.20.7-dZ86T2tea94j7ONmoFm1B --dependency=opencv=opencv-0.0.2.1-zn86wESwVn62SCwEHdGkS --dependency=primitive=primitive-0.6.2.0-EI3NK1Xfv9zEcRtyXK2EwZ --dependency=template-haskell=template-haske
ll-2.12.0.0 --dependency=transformers=transformers-0.5.2.0 --dependency=vector=vector-0.12.0.1-3FWV4ejAWV0FsmvNvoLaed -f-internal-documentation --extra-lib-dirs=/usr/local/lib --exact-configuration
@(System/Process/Log.hs:37:3)

No sign of c++ in there 😱

mgsloan commented 6 years ago

@dukedave That is stack's invocation of opencv-extra's custom setup. So, naturally it doesn't have a mention of c++. If you add a putStrLn or something to the custom Setup.hs I think you will see that it does indeed get invoked. So I don't think that's the problem.

davetapley commented 6 years ago

Here's where I'm at as of now: I strongly believe the problem now (i.e. the ISO C++ forbids declaration of ‘corners’ with no type problem) is that C++11 mode is not enabled, that is consistent with this SO post.

I have confirmed that everything seems to be setup to include the C++, per this SO post.

I've also confirmed that the the version of gcc I have installed locally (and the version which comes in the fpco/stack-build:lts-10.2, both are 5.4.0) have full C++11 support.

Based on this it seems that the only think we should need is the -std=c++11 flag. I have confirmed that is already present in the .cabal files:

https://github.com/LumiGuide/haskell-opencv/blob/84b16541b8316fcd7e82f563e041bdee1fb47489/opencv/opencv.cabal#L108

https://github.com/LumiGuide/haskell-opencv/blob/84b16541b8316fcd7e82f563e041bdee1fb47489/opencv-extra/opencv-extra.cabal#L76

The first SO post I linked does mention setting ghc-options: -pgmlg++, I tried that but it doesn't make a difference.

davetapley commented 6 years ago

I did what @mgsloan suggested and confirmed that yep, Setup.hs is called during stack build. However I did notice that it's only called once, and that invocation does not match the | "configure"elemargs guard, and so the "--with-gcc","c++", "--with-ld","c++" part is never appended. https://github.com/LumiGuide/haskell-opencv/blob/84b16541b8316fcd7e82f563e041bdee1fb47489/opencv-extra/Setup.hs#L6

It's been like that since the beginning though (first for opencv in d84f33e2c8e4b38a1866016f3305d987ca73ff9b, then for -extra in 5c93fededeb0414ded7f92d13e1a44b5c08129a1.

I removed the guard and had it always pass "--with-gcc","c++", "--with-ld","c++", but that didn't change anything.

I tried reverting 6b78bc4c431d693b0bc828cc86708882a26f777c, to no avail.

I spotted --prog-options in the Cabal docs, so I tried adding "--gcc-options", "-std=gnu++11", but no difference.

One final WTF moment: It seems that you can put whatever you like here (e.g. cc-options: fail fail fail), and it doesn't matter, which makes me question whether it's being used at all? https://github.com/LumiGuide/haskell-opencv/blob/84b16541b8316fcd7e82f563e041bdee1fb47489/opencv-extra/opencv-extra.cabal#L76

basvandijk commented 6 years ago

@dukedave thanks for fixing this! Want to do some more debugging: https://github.com/LumiGuide/haskell-opencv/issues/108? ;)

LumiGuide / haskell-opencv

Error when building some C++ source #104