sparsehash-0.6 fails to build with Sun C++ compiler

[GoogleCodeExporter]

What steps will reproduce the problem?
1. CC=/opt/SUNWspro/bin/cc CXX="/opt/SUNWspro/bin/CC -library=stlport4"
./configure
2. gnumake
3.

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

I see a few failures (successful build expected):

a) /opt/SUNWspro/bin/CC -library=stlport4 -DHAVE_CONFIG_H -I. -I.
-I./src/google/sparsehash  -I./src   -g -c -o type_traits_unittest.o `test
-f 'src/type_traits_unittest.cc' || echo './'`src/type_traits_unittest.cc
"src/type_traits_unittest.cc", line 117: Error: The function "exit" must
have a prototype.

b) /opt/SUNWspro/bin/CC -library=stlport4 -DHAVE_CONFIG_H -I. -I.
-I./src/google/sparsehash  -I./src   -g -c -o sparsetable_unittest.o `test
-f 'src/sparsetable_unittest.cc' || echo './'`src/sparsetable_unittest.cc
"./src/google/sparsetable", line 878: Error: The destructor name must match
the class name.

c) /opt/SUNWspro/bin/CC -library=stlport4 -DHAVE_CONFIG_H -I. -I.
-I./src/google/sparsehash  -I./src   -g -c -o hashtable_unittest.o `test -f
'src/hashtable_unittest.cc' || echo './'`src/hashtable_unittest.cc
"./src/google/sparsehash/hash_fun.h", line 45: Error: Multiple declaration
for hash.
"./src/google/sparsehash/hash_fun.h", line 48: Error:
std::__stl_hash_string(const char*) already had a body defined.
"./src/google/sparsehash/hash_fun.h", line 57: Error: Multiple declaration
for std::hash<char*>.

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

$ uname -a
SunOS heli 5.10 Generic_125101-04 i86pc i386 i86pc
$ /opt/SUNWspro/bin/CC -V
CC: Sun C++ 5.8 Patch 121018-10 2007/02/21

Please provide any additional information below.

Let me take it case by case:

a) Changing exit() to std::exit() helps (please see attached diff)

b) src/google/sparsetable code uses explicit destructor call in a form

 buffer[position].value_type::~value_type();

where value_type is a type definition. However, according to my reading of
C++ draft #12.4 (don't have the final standard around) such use of type
aliasing is not allowed:

...
-12- In an explicit destructor call, the destructor name appears as a ~
followed by a type-name that names the destructor's class type. The
invocation of a destructor is subject to the usual rules for member
functions (class.mfct), that is, if the object is not of the destructor's
class type and not of a class derived from the destructor's class type, the
program has undefined behavior (except that invoking delete on a null
pointer has no effect). [Example:

    struct B {
        virtual ~B() { }
    };
    struct D : B {
        ~D() { }
    };

    D D_object;
    typedef B B_alias;
    B* B_ptr = &D_object;

    void f() {
        D_object.B::~B();               //  calls  B's destructor
        B_ptr->~B();                    //  calls  D's destructor
        B_ptr->~B_alias();              //  calls  D's destructor
        B_ptr->B_alias::~B();           //  calls  B's destructor
        B_ptr->B_alias::~B_alias();     //  error, no  B_alias  in class  B
    }
...

Changing destructor call to

 buffer[position].value_type::~T()

fixes the problem (also in the diff attached).

c) sparsehash seems to conflict with stlport implementation in that the
latter does define std::hash<> somewhere internally in standard <string>
header. This is something I did not manage to fix in configure scripts,
probably it makes sense to check <string> header for presence of
std::hash<> implementation as well.

Original issue reported on code.google.com by dennis.c...@gmail.com on 31 May 2007 at 9:03

Attachments:

• sparsehash-0.6.diff

[GoogleCodeExporter]

Interesting -- I didn't realize about exit() being in std.  I'll fix that up.

As for the destructor calls, we've fixed the problem a different way, which 
will be
in the next release.  Thanks for diagnosing what was wrong with the original 
syntax,
though.  It seemed to us like it should be ok -- and indeed is in gcc, though 
not
other compilers.  We couldn't figure out the problem  (though luckily that 
didn't get
in the way of figuring out a fix :-) ).

I'll download stlport and try to fix up the configure scripts.

Original comment by csilv...@gmail.com on 31 May 2007 at 6:54

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I believe the problem with the std::exit is actually because we were missing a
necessary include file.  Can you help test that?  (I don't have access to the 
sun
compiler.)

Try changing the type_traits_unittest.cc back to just exit() (not sys::exit()), 
and
add #include <stdlib.h> at the top of the file.  Does the code compile then?

Original comment by csilv...@gmail.com on 31 May 2007 at 9:00

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 31 May 2007 at 9:04

• Changed state: Started
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks for prompt response! It compiles indeed.

Original comment by dennis.c...@gmail.com on 1 Jun 2007 at 8:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I just made the 0.7 release, which should fix this.

Original comment by csilv...@gmail.com on 11 Jun 2007 at 7:48

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****