sparsehash: configuration error

[jwhowse4]

I am using an Intel Mac Pro running Mac OS 10.8.5 (Mountain Lion) with XCode 5.0.2. When I try to upgrade the port kdevplatform from version 1.5.2 to version 1.6.0 the build fails with the attached error log. Any suggestions for a fix?

Edit: The error log above is symptomatic of configuration errors in sparsehash, where HASH_FUN_H is defined as <tr1/functional> instead of <functional> (see discussion below).

[jwhowse4]

Error log for kdevplatform build

[NicosPavlov]

The definition of HASH_FUN_H should be in sparseconfig.h, from sparsehash port. It seems surprising that the definition would be wrong, but it is true that in my case it is not <tr1/functional> as it seems from your log, but <functional> only. However, these are also different systems (10.8 vs. 10.9 for me).

I see also that you have Macports installed on a custom location, while sparsehash has a pre-compiled binary, where the configuration may not be correct for your system. Does forcing to install sparsehash from source solves the issue?

sudo port -f uninstall sparsehash
sudo port -s install sparsehash

[jwhowse4]

Replying to nicos@…:

The definition of HASH_FUN_H should be in sparseconfig.h, from sparsehash port. It seems surprising that the definition would be wrong, but it is true that in my case it is not <tr1/functional> as it seems from your log, but <functional> only. However, these are also different systems (10.8 vs. 10.9 for me).

I see also that you have Macports installed on a custom location, while sparsehash has a pre-compiled binary, where the configuration may not be correct for your system. Does forcing to install sparsehash from source solves the issue?

sudo port -f uninstall sparsehash
sudo port -s install sparsehash

I do not see how sparsehash could have a precompiled binary since I install everything from source. However, I uninstalled and reinstalled sparsehash as you suggested. I then deactivated the currently active version of kdevplatform and tried to install the new version. The result was the same as previously. I have attached the new log file in the event details have changed.

[jwhowse4]

New error file for kdevplatform

[NicosPavlov]

Well, in this case, I strongly suspect that there is an issue in sparsehash's portfile, since internal symbols seem incorrect (cc'ed the maintainer), as to my understanding, HASH_FUN_H, defined as <tr1/functional> in your log should be <functional>.

In the meantime, that's an ugly workaround, which would also be overridden with updates of sparsehash, but redefining HASH_FUN_H in the file ${prefix}/include/sparsehash/internal/sparseconfig.h should solve this issue.

[jwhowse4]

Replying to nicos@…:

Well, in this case, I strongly suspect that there is an issue in sparsehash's portfile, since internal symbols seem incorrect (cc'ed the maintainer), as to my understanding, HASH_FUN_H, defined as <tr1/functional> in your log should be <functional>.

In the meantime, that's an ugly workaround, which would also be overridden with updates of sparsehash, but redefining HASH_FUN_H in the file ${prefix}/include/sparsehash/internal/sparseconfig.h should solve this issue.

While I agree this is an ugly hack, it does work for me. By the way I also had to redefine HASH_NAMESPACE to std. The question in my mind is why these two variable were not properly defined on my system in the first place.

[NicosPavlov]

Thanks for the feedback. This confirms that the issue is located in the configuration of sparsehash, and that the build issue of kdevplatform is only a symptom. I changed the description accordingly, and assigned the ticket to the maintainer of sparsehash. I may have a look if I find the time, but not being familiar with the details of sparsehash, I may not be very efficient at solving the issue.

[NicosPavlov]

Has duplicate #42755.

By looking in slightly more details, it seems that the discrepancy in the declaration of HASH_FUN_H depends on the compiler. If compiled with gcc or llvm-gcc, it reduces to <tr1/funtional>, while with clang, it reduces to <functional>.

[ryandesign (Ryan Carsten Schmidt)]

Is this still a problem with sparsehash 2.0.3?

[jwhowse4]

Replying to ryandesign@…:

Is this still a problem with sparsehash 2.0.3?

This still seems to be a problem in the sense that in the file sparseconfig.h the variable HASH_FUN_H has the value <tr1/functional> and the variable HASH_NAMESPACE has the value std::tr1. I have attached the build log for sparsehash 2.0.3 on my system. If I am reading it correctly the package builds with clang.

[jwhowse4]

sparsehash 2.0.3 build long

[NicosPavlov]

The issue seems to persist, and it seems to be a gcc vs. clang problem. Clang (apple-clang and macports-clang-3.{4, 5, 6} reduces to <functional>, while gcc-4.8, 4.9 and 5.0 reduce to <tr1/functional>

[jwhowse4]

Replying to nicos@…:

The issue seems to persist, and it seems to be a gcc vs. clang problem. Clang (apple-clang and macports-clang-3.{4, 5, 6} reduces to <functional>, while gcc-4.8, 4.9 and 5.0 reduce to <tr1/functional>

In the build log I attached it appears to me that sparsehash is being built with apple-clang. Am I reading the log wrong? If I am not misreading the log, would you mind explaining how this is a gcc vs. clang issue when my clang built sparsehash reduces to <tr1/functional>? This may be a silly question, I am just trying to understand the issue.

[NicosPavlov]

Sorry, I missed that part. Then please read my previous comment as "on my system". It also means that the issue is more subtle, as while it is a clang vs. gcc issue on my system (10.10.4, XCode 6.4), it is also the case for clang on yours.

[ryandesign (Ryan Carsten Schmidt)]

tr1 is an old implementation of features which eventually became standardized in C++11. libstdc++, which was the default C++ standard library on OS X 10.8 and earlier and is also used by g++ and llvm-g++ on any OS version, supports tr1. Apple's old libstdc++ does not support C++11. Newer versions of libstdc++ used by newer versions of g++ do support C++11. libc++, a new C++ standard library which is the default on OS X 10.9 and later and is used by clang by default on OS X 10.9 and later, supports C++11 and does not support tr1.

The way that the sparsehash port had configured itself was correct for your C++ standard library. The problem, from your log, is that kdevplatform was trying to build using libc++, even though that was not the correct C++ standard library to use on your OS version. It is unclear why kdevplatform is doing this, since it did not indicate that it required C++11, which would be the only reason I know of for requiring libc++ on macOS.

See also #55773 for another manifestation of this problem with textmate which also requires the use of libc++, and ​https://github.com/sparsehash/sparsehash/issues/145 for my unanswered plea to the developers to change how they handle this.

As of MacPorts 2.6.0, we now default to libc++ on 10.6-10.8 instead of libstdc++. We deleted and are in the process of rebuilding all archives that were linked with libc++, but we did not notice that sparsehash also needs to be rebuilt, since it does not have any compiled files and is a header-only library. I will increase its revision to rebuild it.

[ryandesign (Ryan Carsten Schmidt)]

In 18a1b6b37472aa4a717e03e70a51cac3b6fe1590/macports-ports (master):

sparsehash: Rebuild with libc++ on 10.6-10.8

Closes: #42506

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

kdevplatform was trying to build using libc++, even though that was not the correct C++ standard library to use on your OS version. It is unclear why kdevplatform is doing this, since it did not indicate that it required C++11, which would be the only reason I know of for requiring libc++ on macOS.

It was not shown in the old logs attached to this ticket, but since then, kdevplatform was changed to indicate that it does in fact require C++11. So that's why it was using libc++.