[MacPorts] #50128: tesseract @3.04.00_2 build failure: 'unordered_map' file not found
MacPorts
noreply at macports.org
Thu Nov 23 21:28:52 UTC 2017
#50128: tesseract @3.04.00_2 build failure: 'unordered_map' file not found
---------------------------+--------------------------------
Reporter: alexmptrac@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.3.4
Resolution: | Keywords:
Port: tesseract |
---------------------------+--------------------------------
Comment (by ryandesign):
Replying to [comment:3 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 has 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 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 its `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.
--
Ticket URL: <https://trac.macports.org/ticket/50128#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list