configure result in wrong hash namespace/header with gcc 4.1.2
Closed this issue · 7 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1. configure with gcc 4.1.2
2. configure script using hash in __gnu_cxx, but it's
really in tr1
What is the expected output? What do you see instead?
using hash in tr1
What version of the product are you using? On what operating system?
1.9
Please provide any additional information below.
i think gcc 4.1 with patch level >= 1 provide hash function in
tr1 namespace, but m4/stl_hash.m4 only check for __GNUC_MINOR__ < 2.
change the test to this fix the problem:
AC_TRY_COMPILE([#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ <= 1 && __GNUC_PATCHLEVEL__ < 1))
Original issue reported on code.google.com by james.fa...@gmail.com
on 6 Dec 2010 at 10:56
GoogleCodeExporter commented
As the comment in m4/stl_hash.m4 says, "I've seen unexplainable unordered_map
bugs with -O2 on older gcc's." So I purposefully still use the __gnu_cxx hash,
rather than the tr1 hash, with gcc 4.1.2.
Both hashes are available in 4.1.2, so I'm not sure exactly what the problem is
that you're reporting. Do you have code that doesn't work?
Original comment by csilv...@gmail.com
on 6 Dec 2010 at 8:24
- Added labels: Priority-Medium, Type-Defect
GoogleCodeExporter commented
sorry, i did not give any attentions to the comment.
when i migrate to 1.9, it complains about __gnu_cxx. it seems our code's old
version
sparsehash is using the tr1 namespace.
maybe someone manually edit the sparseconfig.h to force using tr1. :)
Original comment by james.fa...@gmail.com
on 7 Dec 2010 at 3:29
GoogleCodeExporter commented
Hmm, what is the exact complaint you're seeing? Can you give a specific
example of a compile command you try to run, and the errors you get in response?
Original comment by csilv...@gmail.com
on 7 Dec 2010 at 4:24
GoogleCodeExporter commented
here it is:
/usr/local/include/google/sparsehash/hashtable-common.h:65: error:
‘operator()’ is not a member of ‘__gnu_cxx::hash<std::basic_string<char,
std::char_traits<char>, std::allocator<char> > >’
our code does not provide a hash function for std::string in __gnu_cxx,
it just force sparsehash to use tr1 instead.
Original comment by james.fa...@gmail.com
on 7 Dec 2010 at 6:37
GoogleCodeExporter commented
Ah, I see what the problem is. __gnu_cxx::hash<> does not provide a default
hash for string, though it does for char*. tr1::hash<> is the other way
around: it does provide hash<string>, but not hash<char*>. The problem isn't
the fact it's in __gnu_cxx, the problem is you're depending on the system to
provide a hash function for you which it's not.
I'm closing this as NotABug since it's really not sparsehash's responsibility
to deal with hash functions at all. The approach you're using now, of forcing
tr1::hash<>, is fine. Another approach would be to just define your own hash
function, so you don't have to worry about what the system provides.
Original comment by csilv...@gmail.com
on 7 Dec 2010 at 6:56
- Changed state: Invalid
GoogleCodeExporter commented
/home/zhangchi/local/include/sparsehash/sparse_hash_map:249:75: instantiated
from 'google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::iterator
google::sparse_hash_map<Key, T, HashFcn, EqualKey,
Alloc>::find(google::sparse_hash_map<Key, T, HashFcn, EqualKey,
Alloc>::key_type&) [with Key = long long unsigned int, T = bool, HashFcn =
__gnu_cxx::hash<long long unsigned int>, EqualKey = std::equal_to<long long
unsigned int>, Alloc = google::libc_allocator_with_realloc<std::pair<const long
long unsigned int, bool> >, google::sparse_hash_map<Key, T, HashFcn, EqualKey,
Alloc>::iterator = google::sparse_hashtable_iterator<std::pair<const long long
unsigned int, bool>, long long unsigned int, __gnu_cxx::hash<long long unsigned
int>, google::sparse_hash_map<long long unsigned int, bool>::SelectKey,
google::sparse_hash_map<long long unsigned int, bool>::SetKey,
std::equal_to<long long unsigned int>,
google::libc_allocator_with_realloc<std::pair<const long long unsigned int,
bool> > >, google::sparse_hash_map<Key, T, HashFcn, EqualKey, Alloc>::key_type
= long long unsigned int]'
GenericNodeMemWrapper.cpp:960:55: instantiated from here
/home/zhangchi/local/include/sparsehash/internal/hashtable-common.h:250:62:
error: 'operator()' is not a member of
'google::sparsehash_internal::sh_hashtable_settings<long long unsigned int,
__gnu_cxx::hash<long long unsigned int>, long unsigned int, 4>::hasher'
Original comment by hewm2...@gmail.com
on 23 Jul 2013 at 5:59
GoogleCodeExporter commented
Sorry I am stumbling across this old issue but on our old servers we found that
you can use boost to fix this by changing the config file to use boost headers.
Change some of the values in src/config.h to be using something similar to this:
/* src/config.h. Generated by configure. */
/* src/config.h.in. Generated from configure.ac by autoheader. */
/* Namespace for Google classes */
#define GOOGLE_NAMESPACE ::google
/* the location of the header defining hash functions */
#define HASH_FUN_H <boost/functional/hash/hash.hpp>
/* the location of <unordered_map> or <hash_map> */
#define HASH_MAP_H <boost/tr1/unordered_map.hpp>
/* the namespace of the hash<> function */
#define HASH_NAMESPACE boost
/* the location of <unordered_set> or <hash_set> */
#define HASH_SET_H <boost/tr1/unordered_set.hpp>
/* Define to 1 if you have the <google/malloc_extension.h> header file. */
/* #undef HAVE_GOOGLE_MALLOC_EXTENSION_H */
/* define if the compiler has hash_map */
#define HAVE_HASH_MAP 0
/* define if the compiler has hash_set */
#define HAVE_HASH_SET 0
/* define if the compiler supports unordered_{map,set} */
#define HAVE_UNORDERED_MAP 1
Original comment by colin.di...@gmail.com
on 2 Apr 2015 at 7:44