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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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. :(
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.
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?
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
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
Opencv has stopped me. I got:
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
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 opencvto obtain the include directories (for the c++ compiler), but now with OpenCV4 is has to bepkg-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
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
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
The OpenCVConfig.cmake file is located at: /usr/lib64/cmake/OpenCV/OpenCVConfig.cmake
I put the line
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
only these files show up in /usr/include/opencv:
However, there is another directory with gobs more .h and .hpp files under another layer of subdirectories:
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
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
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
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