Menu

Compiling MTFMapper on Linux

Ted Miller
2020-06-25
2020-08-01
  • Ted Miller

    Ted Miller - 2020-06-25

    Are there any instructions for compiling MTFMapper on non-Debian-based Linux distributions? I am running CentOS 6, 7, & 8.

     

    Last edit: Ted Miller 2020-06-25
    • Frans van den Bergh

      Hi Ted,

      I have some instructions for building MTF Mapper from source on Ubuntu, which you can download here. The instructions should be (mostly) usable under CentOS, after figuring out the correct package names.

      Note that the whole asciidoc dependency is optional if you are not interested in building things like the man pages.
      Qt is also optional, if you are just interested in the command-line tools, but it is probably worth trying to get the Qt dependencies sorted out.
      The TCLAP and eigen3 dependencies are header-only, so if you cannot find those in packages on CentOS, you can just download their respective sources, and point the cmake process in the right direction.

      Let me know if you have problems with the OpenCV dependency (although it seems to work as described in the notes on both Ubuntu and Gentoo distros without any user intervention). I have not tested with OpenCV 4, so I recommend OpenCV 3.x.

      On the bright side, at least you are not trying to build MTF Mapper on Windows, which is much more painful :)

      Regards,
      Frans

       
  • Ted Miller

    Ted Miller - 2020-07-21

    Opencv has stopped me. I got:

    CMake Error at cmake_helpers/FindOpenCV.cmake:141 (message):
      OpenCV required but some headers or libs not found.  Please specify OpenCV
      directory using OpenCV_DIR env.  variable
    Call Stack (most recent call first):
      CMakeLists.txt:70 (find_package)
    

    The error message is quite unhelpful, as it does not tell me what it cannot find. It is a summary message that says that somewhere in the 82 lines of code above it, something has failed. It tried setting OpenCV_DIR to the paths to OpenCVConfig.cmake and then to cv.h, but neither of those changes the error message.

    I do not speak cmake, so I am quitting.

    Ted Miller in Indiana

     

    Last edit: Ted Miller 2020-07-21
    • Frans van den Bergh

      Hi Ted,

      This may or may not be related to OpenCV4. I run gentoo, and I noticed that the package name has changed, e.g., usually you could run pkg-config --cflags opencv to obtain the include directories (for the c++ compiler), but now with OpenCV4 is has to be pkg-config --cflags opencv4. Could you please check which of the two commands above (in this paragraph) works on your CentOS installation?

      If this is the problem, then I can fix the cmake files that are supposed to locate OpenCV.

      You can also short-circuit the process by telling cmake directly where to find OpenCV's config file. Something like

      cmake .. -DOpenCV_DIR=`find / -name OpenCVConfig.cmake | xargs dirname`
      

      might work. On my gentoo installation, that file is located in /usr/lib64/cmake/opencv4/, which is again a departure from the pre-OpenCV4 convention.

      Anyhow, I would appreciate it greatly if you could let me know which pkg-config command works for you, and perhaps if the cmake command works, then I can modify my cmake scripts accordingly.

      Regards,
      Frans

       
  • Ted Miller

    Ted Miller - 2020-07-23

    My package installer says that opencv 3.4.6 is installed on my Centos 8 laptop.

    I get no answer to pkg-config for opencv2 and opencv4, but

    # pkg-config -cflags opencv
    -I/usr/include/opencv
    

    The OpenCVConfig.cmake file is located at: /usr/lib64/cmake/OpenCV/OpenCVConfig.cmake

    I put the line

    OpenCV_DIR="/usr/lib64/cmake/OpenCV"
    

    before the cmake line, but I still get the error message.

    I don't know if this is relevant, but I noticed that when I execute

    locate opencv | grep include
    

    only these files show up in /usr/include/opencv:

    $ ls /usr/include/opencv
    cvaux.h    cv.h    cvwimage.h  cxcore.hpp   cxmisc.h   ml.h
    cvaux.hpp  cv.hpp  cxcore.h    cxeigen.hpp  highgui.h
    

    However, there is another directory with gobs more .h and .hpp files under another layer of subdirectories:

    $ ls /usr/include/opencv2/
    aruco            highgui.hpp           shape
    aruco.hpp        imgcodecs             shape.hpp
    bgsegm.hpp       imgcodecs.hpp         stereo
    bioinspired      img_hash              stereo.hpp
    bioinspired.hpp  img_hash.hpp          stitching
    calib3d          imgproc               stitching.hpp
    calib3d.hpp      imgproc.hpp           structured_light
    ccalib           line_descriptor       structured_light.hpp
    ccalib.hpp       line_descriptor.hpp   superres
    core             ml                    superres.hpp
    core.hpp         ml.hpp                surface_matching
    cvconfig.h       objdetect             surface_matching.hpp
    cvv              objdetect.hpp         tracking
    cvv.hpp          opencv.hpp            tracking.hpp
    datasets         opencv_modules.hpp    video
    dpm.hpp          optflow               video.hpp
    face             optflow.hpp           videoio
    face.hpp         phase_unwrapping      videoio.hpp
    features2d       phase_unwrapping.hpp  videostab
    features2d.hpp   photo                 videostab.hpp
    flann            photo.hpp             ximgproc
    flann.hpp        plot.hpp              ximgproc.hpp
    freetype.hpp     reg                   xobjdetect.hpp
    fuzzy            rgbd                  xphoto
    fuzzy.hpp        rgbd.hpp              xphoto.hpp
    hfs.hpp          saliency
    highgui          saliency.hpp
    

    Each of the entries that does not end in .h is a subdirectory with more files in it.

    I don't know which file(s) you use, and which file(s) cmake is looking for.

    Next attempt--I added your special line "cmake .. -DOpenCV_DIR=...". That sat and churned for a while, then exited with a message about not being able to find CMakeLists.txt. After scratching my head for a couple of minutes, and figuring out where the top CMakeLists.txt was located, I changed the .. in your special cmake line to ../mtfmapper-code. That seemed to make that happy, so then it said it couldn't find ZLIB_LIBRARY. I looked and zlib was installed, but not zlib-devel, so I added that to the dependencies in the file.

    Then I got the error

    a2x: ERROR: "dblatex" -t pdf -p "/etc/asciidoc/dblatex/asciidoc-dblatex.xsl" -s "/etc/asciidoc/dblatex/asciidoc-dblatex.sty"   "/home/tmiller/compiling/workspace/mtfmapper/manpages/mtf_generate_rectangle.1.xml" returned non-zero exit status 127
    

    I remembered that I did not see Latex being installed with asciidoc (as you commented that it would be on Ubuntu). dblatex was not installed on my system, but there is a package by that name. Another addition to the dependencies? Not so quick. This does indeed want to pull in all of Latex, with an installed size of 554MB. This is a laptop with a non-upgradable eMMC hard drive(a BGAchip soldered to the motherboard)--only 128G for dual boot CentOS + Win10. Only have a 44G root drive, so I watch for big items like Latex, and think hard about them.

    You said "Note that the whole asciidoc dependency is optional if you are not interested in building things like the man pages." From what I read in a cmake file, it was supposed to not make the man files if asciidoc was not installed, so I uninstalled asciidoc. Still wouldn't compile until I deleted the CMakeCache.txt file, which kept where a2x was located. Then it actually got into compiling. After a bit of a wait (the laptop is optimized for low weight and long battery life) I have seen the GUI, and it works!

    I am attaching the modified script that I used for the compile.

    As my backup plan, I am creating a Virtual Machine with Lubuntu 1804 on it, but that is taking its good old time in the next room. Even worse is that I started with too small a hard drive, got well into the installation, then it quit because root drive was out of room. Ended up starting the install over. :(

    Ted Miller in Indiana

     
    • Frans van den Bergh

      Hi Ted,

      Thank you very much for going to all this trouble!

      I have managed to reproduce your installation steps in a Docker using the centos:latest image. This required a few extra steps to ensure all the CentOS repositories were available, but I think this only comes down to three extra lines. I also added some steps to download TCLAP, which appears to be the only dependency that is not available in any of the usual CentOS repos. Fortunately, this does not require a compile step, but an extra argument has to be added to the cmake command.

      With regards to the OpenCV problem, I think I have a workable solution. Back when I first released MTF Mapper (2011?) it was necessary to help cmake find the OpenCV dependencies by adding an extra "module" script to the MTF Mapper cmake scripts. I have just tested on gentoo, Ubuntu, and CentOS, and none of these distros require any help finding OpenCV. In fact, my FindOpenCV.cmake script is actually the reason why cmake fails to find OpenCV! I have now removed the FindOpenCV.cmake script from the MTF Mapper source, so this should fix the problem (for now). With a bit of luck this will not affect Mac OS X builds (cannot test that myself), and it should have no impact on Windows builds (which have always required you to explicitly provide the OpenCV_DIR path anyway).

      Would you mind if I upload your CentOS build script (with my modifications, but with your attribution intact) onto the MTF Mapper SourceForge site? Something like a "contributions" directory in the downloads section ? I have attached a draft of the modified script.

      Regards,
      Frans

       
  • Ted Miller

    Ted Miller - 2020-08-01

    Frans,

    I decided that I wanted to civilize this script before turning it loose on the public. I put some explanation at the top, and some other things.

    I also found that the script did not install MAKE. Of course that made CMake throw an error.

    I had a brand new Centos 8 Virtual Machine that I had set up, so I used the script in it. After some tweeks it runs OK, though I wish I could easily try it on a blank Centos 8 computer, to see if I missed anything.

    I am attaching the updated version. You have permission to "release" it. (I have added credit for your work on the script.)

    BTW, have you considered making a Docker version available as an option for Linux users who don't want to compile it?

    Ted Miller

     

Log in to post a comment.