search

jorensorilla / sparsehash

Automatically exported from code.google.com/p/sparsehash
0 stars 0 forks source link

google-sparsehash v0.8.1 does not build on Solaris/x86_64 #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Build the package on Solaris/x86_64 with Sun Studio 12 in 64-bit mode,
for instance

 $ CC='/tb/soft/sun/x86_64/studio12/SUNWspro/bin/cc' CFLAGS=' -D_REENTRANT
-D_LARGEFILE64_SOURCE -mt -xCC   -g -xs   -xtarget=opteron -m64  -DSOLARIS
-DSOLARIS64 -D_POSIX_PTHREAD_SEMANTICS'
CXX='/tb/soft/sun/x86_64/studio12/SUNWspro/bin/CC' CXXFLAGS=' -D_REENTRANT
-D_LARGEFILE64_SOURCE -mt -library=stlport4 -g -xs -xtarget=opteron -m64 
-DSOLARIS -DSOLARIS64 -D_POSIX_PTHREAD_SEMANTICS' CPPFLAGS='-DSOLARIS
-DSOLARIS64 -D_POSIX_PTHREAD_SEMANTICS
 $ gmake

What is the expected output? What do you see instead?

Package fails to build in two places:

 1. At the configure step, 'fgrep' is not found as it is not a standard
utility on Solaris (suggested fix is in the attachment); also, there was a
problem with build output redirection -- src/config.h was referred to using
$(top_srcdir) rather than $(top_builddir)

 2. After configuration step, one of the unit tests (hashtable_unittest.cc)
yields compilation errors:

"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 699: Error: Could not find a match for write_item needed in
test_string<google::dense_hashtable<std::string, std::string, StrHash,
Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>>(bool).
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 754:     Where: While instantiating
"test_string<google::dense_hashtable<std::string, std::string, StrHash,
Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>>(bool)".
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 754:     Where: Instantiated from test<google::dense_hashtable<char*,
char*, std::hash<const char*>, Identity<char*>, strcmp_fnc,
std::allocator<char*>>, google::dense_hashtable<std::string, std::string,
StrHash, Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>, google::dense_hashtable<int, int,
std::hash<int>, Identity<int>, std::equal_to<int>, std::allocator<int>>>(bool).
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 846:     Where: Instantiated from non-template code.
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 724: Error: Could not find a match for read_item needed in
test_string<google::dense_hashtable<std::string, std::string, StrHash,
Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>>(bool).
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 754:     Where: While instantiating
"test_string<google::dense_hashtable<std::string, std::string, StrHash,
Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>>(bool)".
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 754:     Where: Instantiated from test<google::dense_hashtable<char*,
char*, std::hash<const char*>, Identity<char*>, strcmp_fnc,
std::allocator<char*>>, google::dense_hashtable<std::string, std::string,
StrHash, Identity<std::string>, std::equal_to<std::string>,
std::allocator<std::string>>, google::dense_hashtable<int, int,
std::hash<int>, Identity<int>, std::equal_to<int>, std::allocator<int>>>(bool).
"/home/cdi/src/tbricks/trunk/src/thirdparty/sparsehash/0.8.1/src/src/hashtable_u
nittest.cc",
line 846:     Where: Instantiated from non-template code.

What version of the product are you using? On what operating system?

It's google-sparsehash v0.8.1 on 
SunOS hostname 5.10 Generic_125101-09 i86pc i386 i86pc

Please provide any additional information below.

Attached is suggested fix for the first issue, it just uses AWK (NAWK on
Solaris) instead of fgrep. I do not have a clue for the second problem yet.

Original issue reported on code.google.com by dennis.c...@gmail.com on 7 Aug 2007 at 7:24

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by csilv...@gmail.com on 7 Aug 2007 at 7:47

GoogleCodeExporter commented 9 years ago 
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.

Original comment by csilv...@gmail.com on 7 Aug 2007 at 9:38

GoogleCodeExporter commented 9 years ago 
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.

Original comment by dennis.c...@gmail.com on 20 Aug 2007 at 2:29

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by csilv...@gmail.com on 20 Aug 2007 at 6:30

GoogleCodeExporter commented 9 years ago 
Sparsehash 0.9 was just released, which should fix this problem.

Original comment by csilv...@gmail.com on 9 Oct 2007 at 10:39