tesseract 4.1.1 compile fails on macOS with a case insensitive filesystem

[mdaniel]

Environment

• Tesseract Version: 4.1.1
• Commit Number: 4.1.1
• Platform: Darwin macbook-pro 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64

Current Behavior:

Compiling 4.1.1 on macOS 11.4 (Big Sur) using the provided Xcode SDK, clang++ and a case-insensitive filesystem produces a compilation error due to the combination of the macOS SDK having #include <version> in a header file and the VERSION file in the root of the tesseract distribution

This is a sibling issue to Homebrew/homebrew-core#78450 where they asked me to report it here

Expected Behavior:

Compilation succeeds even with an SDK that has #include <version> in it

Suggested Fix:

• Maybe rename the VERSION file to VERSION.txt
• or perhaps avoid having -I. in the CPPFLAGS to keep the root directory out of the include path
• or perhaps give explicit guidance to build using a subdirectory which also allows the build to succeed (yes, I know that's the cmake one, but a lot of autotools based builds similarly recommend building with objdir != srcdir)

I tried to reproduce this failure using GitHub Actions but it seems their macos build agents are not new enough to reproduce this failure

[stweil]

This was fixed in git master (see commit bf3421f). A similar fix is still needed for the 4.1 branch.

Builds using a subdirectory show the same problem.

A lot of other projects are affected by the same problem (for example QEMU). So ideally the issue should be fixed by Apple on their side.

[stweil]

Commit 6dc4b18 fixes the 4.1 branch.

More fixes are still required for make training on MacOS to fix ld: library not found for -lpango-1.0.

[stweil]

More fixes are still required for make training on MacOS to fix ld: library not found for -lpango-1.0.

Fixed in commit dbc79b0.

[carlocab]

A lot of other projects are affected by the same problem (for example QEMU). So ideally the issue should be fixed by Apple on their side.

Not really sure what there is for Apple to fix here. Things that Apple can do:

1. Make file systems case-sensitive.
2. Change the version header into something else.
3. Patch clang so that it searches for headers in a case-sensitive manner. (If this is even possible while the file system is still case-insensitive.)

1 is a huge breaking change, and is unlikely to happen. 2 would violate the C++ standard. I don't think we want a non-standards-compliant compiler. 3 won't fix the same issues for users who try to compile software with GCC (when GCC has implemented enough of C++20 -- not sure it has), or with a Clang that isn't provided by Apple.

[stweil]

2 would violate the C++ standard.

Does the C++ standard require an include file called "version"? Even if it does, there is no need to include it from other system header files. Other implementations of the C++ standard don't do that.

[stweil]

Make file systems case-sensitive.

That's already supported. OpenWRT for example suggests a case-sensitive mount for builds on MacOS.

[carlocab]

Does the C++ standard require an include file called "version"?

Yes.

Even if it does, there is no need to include it from other system header files. Other implementations of the C++ standard don't do that.

They don't do it yet. They will. See https://bugs.llvm.org/show_bug.cgi?id=42540.

That's already supported. OpenWRT for example suggests a case-sensitive mount for builds on MacOS.

Ok, so, as an alternative to sanitising your include paths, are you proposing that everyone else instead mount a case-sensitive file system and move their source tree and SDK there whenever they want to build something? Or are you proposing that Apple implement some magic hackery that makes the file system case-sensitive whenever anyone tries to use clang++ or g++ or any other C++ compiler?

[stweil]

They don't do it yet. They will.

Maybe I should have been clearer. Current implementations of the latest C++ standard on Linux provide the version header file, but don't include it from other header files. That implementation would work fine for Tesseract even on case insensitive file systems.

are you proposing that everyone else instead mount a case-sensitive file system

No, I don't propose that. I fixed the issue for Tesseract 4.1 and master (so it can be closed here). But I also think that Apple could have found a better solution to implement the standard. And mounting a case-sensitive file system can be one way to handle the problem if other alternatives are not possible.

[amitdo]

or perhaps give explicit guidance to build using a subdirectory which also allows the build to succeed (yes, I know that's the cmake one, but a lot of autotools based builds similarly recommend building with objdir != srcdir)

cd tesseract
./autogen.sh
cd build
../configure
make
sudo make install
sudo ldconfig

but according to @stweil

Builds using a subdirectory show the same problem.

[stweil]

Our documentation also includes several examples for autotools builds in subdirectories.

[stweil]

I close this issue because it is fixed in the 4.1 branch.