Page MenuHome GnuPG

gpgme: `make dist` introduced VERSION can clash with new C++ <version>
Closed, ResolvedPublic


I ran into this when building from gpgme-1.9.0.tar.bz2 as part of building LibreOffice, on macOS (on a case-insensitive file system) against trunk LLVM libc++ (that includes a <version> header file that gets included from other libc++ headers like <string>): "When compiling e.g. [...]/lang/cpp/src/parser/exception.cpp, libtool adds -I../../.. (presumably to find files like [...]/config.h), and including e.g. <string> internally includes <version> now, and [...]/VERSION happens to win. [...] (An alternative approach might have been to use -iquote../../.. instead of -I../../.., but that's probably hard to shoehorn into the libtool-generated compiler invocation.)", see "external/gpgmepp: Clash between VERSION and trunk libc++ <version>". (And what I do for LibreOffice for now is to remove the VERSION file from the unpacked tarball, and nothing appears to be missing it.)

I checked that recent trunk gpgme make dist still generates the VERSION file into the tarbal's root directory; what I didn't check is that building from the tarball would still run into the issue where a file is compiled with some -I switch pointing at the tarball's root directory, where it would erroneously pick up the VERSION file for an #include <version> in one of the libc++ headers.

Revisions and Commits

Event Timeline

Sorry, I am not sure whether I understand the problem. Sure we have a file VERSION in the top directory but from where and why is it included? Is that some libc++ includes a file "VERSION.h" and somehow the preprocessor includes the file "VERSION"? IS that specified in a new revision of a standard?

C++2a will have a <version> header, so some trunk libc++ headers now (indirectly) #include <version>, and on a case-insensitive file-system, when compiling a gpgme source file with "unlucky" -I../../.. switches against such trunk libc++, that can mean that such an #include <version> picks up gpgme's VERSION file.

werner claimed this task.

I moved the location of config.h to a new "conf" subdirectory. This should solve the issue. Thanks for the report.

To be released with 1.12.