google-sparsehash v0.8.1 does not build on Solaris/x86_64 about sparsehash HOT 5 CLOSED

Thanks for the report!  I don't have access to a sun C compiler, so that's 
helpful.

I've taken the awk script (with slight modifications) to replace fgrep -- even 
though
we could probably figure out how to make solaris grep emulate fgrep, I'm using 
enough
obscure grep flags that awk is probably safer.  (Though I don't know how 
portable
stuff like ARGIND is!)

As for debugging the second problem: the issue is that sun's STL has a 
different type
for its hashtable iterators than gcc's STL.  I'll see if I can use a typename 
to work
around this.

I looked into this more, and I was mistaken in my original diagnosis: all the 
code is
sparsehash code, not the compiler's STL code at all.

I'm mystified by the error.  I'll summarize the important part of it:
   line 724: Error: Could not find a match for write_item needed in
test_string<google::dense_hashtable<std::string, std::string,
(There's an identical error message for read_item).

When test_string calls write_item, the write_item argument has the type of the
hashtable key, in this case std::string.  But we do have a write_item that 
matches
std::string:
   static void write_item(FILE *fp, const string &val) {

I don't know why that doesn't match.  Note the compiler doesn't complain about a
similar call to "test<google::sparse_hashtable<std::string, std::string, ...>", 
which
should have identical type information.

If you can find out what's going on, I'll fix it.  But otherwise, I don't 
really know
what to do.

It seems to be connected to static linkage of 
read_item()/write_item()/free_item()
functions. A friend of mine, Sun Micro employee who works on Sun Studio, told 
me that
the Standard prohibits calls to static functions with template parameters. Sun
documentation provides a few words on the subject, see "Calling Dependent Static
Functions From a Function Template":

 http://developers.sun.com/sunstudio/documentation/ss11/mr/READMEs/c++.html

If I get it right, it refers to C++ Standard 14.6.4.2 - Candidate functions
[temp.dep.candidate]:

-1- For a function call that depends on a template parameter, if the function 
name is
an unqualified-id but not a template-id, the candidate functions are found 
using the
usual lookup rules (basic.lookup.unqual, basic.lookup.koenig) except that:

    * For the part of the lookup using unqualified name lookup (basic.lookup.unqual),
only function declarations with external linkage from the template definition 
context
are found.

Removing "static" linkage declarator (please see the patch) makes the project 
built
on Solaris.

I'm glad you figured out what's going on!  I've fixed the code to use an 
anonymous
namespace instead of 'static', so this should be fixed in the next release.

Sparsehash 0.9 was just released, which should fix this problem.