tesseract @3.04.00_2 build failure: 'unordered_map' file not found

[alexmptrac@…]

MacOS version: 10.7.5
XCode version: 4.6.3

Tesseract @3.04.00_2 is failing to install on two machines here, both running Lion. This problem came up as part of a routine 'port upgrade outdated' (previous versions of tesseract worked OK on these systems).

Googling for the compiler error found this page, which sounds relevant, though it isn't clear to me what to do to fix the problem: ​http://stackoverflow.com/questions/26233011/what-could-cause-clang-to-not-find-the-unordered-map-header

[alexmptrac@…]

Cc Me!

[Blokkendoos (Johan)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

If that page is correct, then this software now requires C++11 and the port should indicate this by including the cxx11 1.0 portgroup. Unfortunately this means the port cannot be compiled in a default MacPorts setup on Mac OS X 10.8 or earlier; see LibcxxOnOlderSystems for the workaround.

[fulopt (Tamás FÜLÖP)]

I have run into the same problem with tesseract @3.02.02 during installing gimp.

(Mac OS X 10.7.5, Xcode 4.6.3)

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

then this software now requires C++11

No that doesn't appear to be correct, since the port still builds fine on Leopard and Snow Leopard, which have no built-in C++11 support.

The configure script checks whether the compiler supports C++11. On Leopard and Snow Leopard, the g++-4.2 compiler is used, and the configure script correctly determines that the compiler does not support C++11 and then apparently uses fallback pre-C++-11 implementations.

On Lion and later, the compiler is clang++, and it determines that the compiler does support C++11. But even though that is true, on Lion and Mountain Lion, the default C++ library, libstdc++, does not support C++11.

When the configure script detects that the compiler supports C++11 on macOS with clang, it adds -stdlib=libc++ to LDFLAGS, but we still see a build failure because the author of the configure script forgot that -stdlib=libc++ would also have to be added to CXXFLAGS. We are using tesseract 3.04.01 in MacPorts, which is not the latest version, but the latest code upstream has not fixed this problem. I don't know if this problem has been reported to the developers yet; if not, it should be.

If we wanted to have tesseract use libc++ on Lion and Mountain Lion, we would want to set configure.cxx_stdlib libc++ on those systems. That will make MacPorts add -stdlib=libc++ to CXXFLAGS. The potential problem with this, and the reason why we don't go setting this flag on arbitrary ports on a whim, is that tesseract's dependencies would still have been built with libstdc++. If a libc++-using tesseract tries to exchange C++ objects with any of its dependencies' libraries that were built with libstdc++, that will fail.

So it might be better if we base our decision on the value of configure.cxx_stdlib. If it's libc++, use C++11; if not, don't. I'm not sure if there's a flag we can use to convince the configure script to behave that way, or if we have to modify the configure script.

[markemer (Mark Anderson)]

In 1b655b8f6dae92268712ca6ff6900ab60008f53e/macports-ports:

Update Tesseract to 03.05.01

• Update Tesseract to 03.05.01
• Enable building with CMake

Fixes: #54006
Closes: #50128
Closes: #50118