Opened 10 years ago

Closed 4 years ago

Last modified 4 years ago

#42506 closed defect (fixed)

sparsehash: configuration error

Reported by: jwhowse4 Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: NicosPavlov
Port: sparsehash

Description (last modified by NicosPavlov)

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).

Attachments (3)

kdevplatform+subversion_main.log (2.3 MB) - added by jwhowse4 10 years ago.
Error log for kdevplatform build
kdevplatform_main_new.log (2.5 MB) - added by jwhowse4 10 years ago.
New error file for kdevplatform
sparsehash_main.log (66.3 KB) - added by jwhowse4 8 years ago.
sparsehash 2.0.3 build long

Change History (18)

Changed 10 years ago by jwhowse4

Error log for kdevplatform build

comment:1 Changed 10 years ago by 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

comment:2 in reply to:  1 Changed 10 years ago by 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.

Changed 10 years ago by jwhowse4

Attachment: kdevplatform_main_new.log added

New error file for kdevplatform

comment:3 Changed 10 years ago by NicosPavlov

Cc: hum@… added

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.

comment:4 in reply to:  3 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by NicosPavlov

Cc: hum@… removed
Description: modified (diff)
Owner: changed from macports-tickets@… to hum@…
Port: sparsehash added; kdevplatform removed
Summary: kdevplatform build failuresparsehash: configuration error

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.

comment:6 Changed 10 years ago by 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>.

comment:7 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Is this still a problem with sparsehash 2.0.3?

comment:8 in reply to:  7 Changed 8 years ago by 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.

Changed 8 years ago by jwhowse4

Attachment: sparsehash_main.log added

sparsehash 2.0.3 build long

comment:9 Changed 8 years ago by 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>

comment:10 in reply to:  9 Changed 8 years ago by 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.

Last edited 8 years ago by jwhowse4 (previous) (diff)

comment:11 Changed 8 years ago by 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.

comment:12 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from humem to macports-tickets@…
Status: newassigned

comment:13 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to ryandesign
Status: assignedaccepted

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.

comment:14 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: acceptedclosed

In 18a1b6b37472aa4a717e03e70a51cac3b6fe1590/macports-ports (master):

sparsehash: Rebuild with libc++ on 10.6-10.8

Closes: #42506

comment:15 in reply to:  13 Changed 4 years ago by 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++.

Note: See TracTickets for help on using tickets.