Macros HASH_FUN_H/HASH_NAMESPACE has to be replaced by actual location of the header

[GoogleCodeExporter]

I have this port compiled by system compiler on FreeBSD (currently gcc-4.2.1).
But I am compiling my code using google-sparcehash-1.1 with the newest
gcc-4.3.0.

autconf placed the line '#define HASH_FUN_H <ext/hash_fun.h>' into
'/usr/local/include/google/sparsehash/sparseconfig.h', but this is based on
the system compiler 4.2.1. And in 4.3.0 hash part of STL changed: now hash
template moved from __gnu_cxx into std namespace.

Suggested fix:
Please remove HASH_FUN_H and HASH_NAMESPACE from autoconf and make it based
on gcc version:
#define GCC_INT_VERSION \
  (__GNUC__*100+__GNUC_MINOR__*10+__GNUC_PATCHLEVEL__)

#if GCC_INT_VERSION<430
// do the old way
#else
// do the new way
#endif

Original issue reported on code.google.com by visa_des...@yahoo.com on 13 Apr 2008 at 5:35

[GoogleCodeExporter]

Hmm, this is interesting.  I guess people have a different expectation about 
what
kinds of configuration are required when a project consists only of headers, 
then
when it's headers plus libraries (say).

I'm not so excited about making the code depend on gcc version -- it means the 
code
will get out of date by default when new gcc's are released, and also means 
that you
can't really use a stl implementation separate from the gcc one.  I think it's 
better
to have the code discover the right location at configure-time.

I'm hoping in practice this will cease to be an issue in the next few years, as 
the
STL ABI is standardized (in particular, with tr1 all these headers will finally 
live
in a standard location).  In the meantime, I think the best bet is to just 
re-install
this package (and indeed any package that has .h files that depend on stl) when
upgrading gcc's.  Or just edit the .h files by hand (which should be easy to do 
since
it's all restricted to the config.h file).

I'm marking this Will Not Fix, but if a lot of people are finding this 
situation to
be difficult for them, feel free to mark it on this bug report, so we can keep 
it in
mind going forwaard.

Original comment by csilv...@gmail.com on 14 Apr 2008 at 10:44

• Changed state: WontFix