Need to compile the libGeos using Sun Studio12 on Solaris10

[satyajitt]

We are trying to compile the libGeos using Sun Studio12 (thats the need). Any help with the below would be appreciated. Thanks in advance.

In ConvexHull?.cpp:

1) Line 272,

sort(pts.begin(), pts.end(), RadiallyLessThen(pts[0]));

Name-space std missing

std::sort(pts.begin(), pts.end(), RadiallyLessThen(pts[0]));

2) Line 167,

dest.erase( unique(dest.begin(),dest.end()), dest.end() );

Name-space std missing

dest.erase( std::unique(dest.begin(),dest.end()), dest.end() );

3) After these changes, the following error appears:

CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -ansi passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored otherwise
"../../source/headers/geos/platform.h", line 59: Warning: #warning "Could not find 64bit integer definition!".
"../../source/headers/geos/geom/Coordinate.inl", line 140: Warning: Shift count is too large.
"ConvexHull.cpp", line 122: Warning: inputPts hides geos::algorithm::ConvexHull::inputPts.
"ConvexHull.cpp", line 161: Warning: inputPts hides geos::algorithm::ConvexHull::inputPts.
"ConvexHull.cpp", line 210: Error: Could not find a match for std::vector<const geos::geom::Coordinate*>::assign(__rwstd::__rb_tree<const geos::geom::Coordinate*, const geos::geom::Coordinate*, __rwstd::__ident<const geos::geom::Coordinate*, const geos::geom::Coordinate*>, geos::geom::CoordinateLessThen, std::allocator<const geos::geom::Coordinate*>>::const_iterator, __rwstd::__rb_tree<const geos::geom::Coordinate*, const geos::geom::Coordinate*, __rwstd::__ident<const geos::geom::Coordinate*, const geos::geom::Coordinate*>, geos::geom::CoordinateLessThen, std::allocator<const geos::geom::Coordinate*>>::const_iterator) needed in geos::algorithm::ConvexHull::reduce(std::vector<const geos::geom::Coordinate*>&).
1 Error(s) and 4 Warning(s) detected.
*** Error code 1
make: Fatal error: Command failed for target `ConvexHull.lo'

Unable to build on either x86, amd64 or SPARC

[mloskot]

Thanks for the report. Unfortunately I don't have access to Solaris platform, so I'm unable to compile GEOS using Sun Studio on this OS.

Anyway, I will try to help.

Regarding 1) and 2)

The missing std in ConvexHull.cpp has been fixed in SVN trunk, see lines 167 and 272.

Regarding 3)

This one is a little mysterious because the code looks OK to me.

I would suggest to try two things:

a) Perhaps including vector header at the beginning of ConvexHull?.cpp file would help. However, I'm not very sure about that.

b) Try to replace the line that causes the error (ConvexHull?.cpp, line 210):

inputPts.assign(reducedSet.begin(), reducedSet.end());

with this:

std::vector tmp(reducedSet.begin(), reducedSet.end());
inputPts.swap(tmp);

It's clear, the vector construction and swapping is slower than single call of std::vector::assign but please try it to see if the problem is in C++ library on Solaris.

I hope it helps.

[varundhussa]

I tried to build it with the source change. However, I am getting the following error:

"ConvexHull?.cpp", line 123: Warning: inputPts hides geos::algorithm::ConvexHull::inputPts. "ConvexHull?.cpp", line 162: Warning: inputPts hides geos::algorithm::ConvexHull::inputPts. "ConvexHull?.cpp", line 212: Error: No parameters provided for template. "ConvexHull?.cpp", line 212: Error: Cannot use rwstd::rb_tree<const geos::geom::Coordinate*, const geos::geom::Coordinate*, rwstd::ident<const geos::geom::Coordinate*, const geos::geom::Coordinate*>, geos::geom::CoordinateLessThen?, std::allocator<const geos::geom::Coordinate*>>::const_iterator to initialize int. "ConvexHull?.cpp", line 213: Error: Formal argument x of type std::vector<const geos::geom::Coordinate*>& in call to std::vector<const geos::geom::Coordinate*>::swap(std::vector<const geos::geom::Coordinate*>&) is being passed int. 3 Error(s) and 4 Warning(s) detected.

[pramsey]

There is some information here that might be helpful.  http://wikis.sun.com/display/SunStudio/Using+Sun+Studio+for+open+source+apps

[mloskot]

I've played a little with building GEOS using SUN Studio (version 0.2008.11-0.86) and my investigation suggests me that the problem is with missing deduction of template parameters in C++ library by SUN.

By default, SUN C++ library defines _RWSTD_NO_MEMBER_TEMPLATES which disables templatized version of std::vector<T>::assign() method (from file /opt/SunStudioExpress/prod/include/CC/Cstd/vector):

#ifndef _RWSTD_NO_MEMBER_TEMPLATES
template<class InputIterator>
void assign (InputIterator first, InputIterator last)
{
   erase(begin(), end());
   typedef _TYPENAME _RWdispatch<InputIterator>::_RWtype _RWtype;
   __insert_aux(begin(), first, last, _RWtype());
}
...

This is standard method defined in C++, so this is problem with SUN Studio. GEOS uses this version of assign() a lot.

Fortunately, there is workaround for this. In ConvexHull?.cpp, you can replace following line (somewhere close to line 210):

   inputPts.assign(reducedSet.begin(), reducedSet.end());

with this equivalent impementation:

   inputPts.erase(inputPts.begin(), inputPts.end());
   std::copy(reducedSet.begin(), reducedSet.end(), std::back_inserter(inputPts));

plus, add this include at the top of the ConvexHull?.cpp file, somewhere around #include <algorithm>:

#include <iterator>

[mloskot]

Unfortunately, SUN Studio fails building GEOS with another compilation error:

"../../source/headers/geos/geomgraph/NodeMap.h", line 91: Error: Cannot use std::pair<geos::geom::Coordinate*const, geos::geomgraph::Node*> to initialize std::pair<geos::geom::Coordinate*, geos::geomgraph::Node*>.

Looks like enabling compilation of GEOS for SUN compiler + SUN C++ library may be a hassle. What about using STLPort which is shipped and available with SUN Studio? It should be  as easy as adding this flat to CXXFLAGS:

-library=stlport4

[pramsey]

GEOS compiles perfectly well under the GNU toolchain in opensolaris. I'm punting this forward to 3.2.

[pramsey]

This issue awaits someone who cares enough to fix or fund it. Punting to 3.3

[rsparapa]

I believe that I might be able to secure funding for this. We are using CC: Sun C++ 5.10 SunOS_i386 2009/06/03. Please contact me to discuss. Thanks.

[strk]

Replying to rsparapa:

I believe that I might be able to secure funding for this. We are using CC: Sun C++ 5.10 SunOS_i386 2009/06/03. Please contact me to discuss. Thanks.

I might be available to work on this. Can't find your email address though. Mine is: strk@…

[strk]

I won't be working on this (no funding secured finally...)

[rroliver]

Solaris RW libCstd workarounds

[rroliver]

Another RW libCstd workaround so that you can --enable-cassert

[rroliver]

RW libCstd workarounds for the geos testsuite

[rroliver]

Greetings,

Find attached workarounds to get geos-3.1.1 to build on Solaris 10 with Sun Studio 12 against the RogueWave? libCstd library.

Workarounds are dependent on the macro _RWSTD_NO_MEMBER_TEMPLATES being defined (not sure if this is the appropriate macro to use, but hey...)

I am no C++ programmer, so someone may want to go over what I have done here to ensure it is sane ;)

There still is an issue during link time with multiple symbol definitions if GEOS_INLINE is defined, though everything compiles and links if --disable-inline is provided during configure.

Best Regards [R]

[pramsey]

Any chance you could do an autoconf test for the sun stuff rather than a magic macro?

[rroliver]

Replying to pramsey:

Any chance you could do an autoconf test for the sun stuff rather than a magic macro?

I can give it a shot... depends on whether you want to test for the existence of the macro during a c++ conftest or test to see whether compilation fails for something like

#include <vector>

main()
{
std::vector<int> v1;
std::vector<int> v2;

v2.insert(v1.begin(),v1.end());

return 0;
}

and set BROKEN_RW_WORKAROUND or such

The magic macro is one of a few defined by Sun's RW libCstd that are set depending on the limitations of the c++ library. such as

RWSTD_NO_MEMBER_TEMPLATES
RWSTD_NO_FRIEND_TEMPLATES
RWSTD_NO_MEM_CLASS_TEMPLATES
RWSTD_NO_TEMPLATE_TEMPLATE
RWSTD_NO_TEMPLATE_ON_RETURN_TYPE

I didn't know which ones were appropriate to test for for each error.

[mloskot]

The libCstd is an old and incomplete C++ library. What's the point in supporting it, especially when Sun does officially support complete alternative based on STLport? It's a matter of one switch. GEOS specifies requirement regarding Visual C++ and incomplete libraries shipped with Visual C++ is not supported, so why to make exception for Sun Studio/libCstd?

[rroliver]

Replying to mloskot:

The libCstd is an old and incomplete C++ library. What's the point in supporting it, especially when Sun does officially support complete alternative based on STLport?

And we could also use gnu libstdc++ or apache libstdcxx, but we dont use them for the same reasons.

They are incompatible when linking with any libraries compiled against libCstd, and by default on solaris C++ code is shipped compiled against libCstd.

[mloskot]

@rroliver IMHO this is Sun's problem and the toolset provided by Sun to resolve this issues, not third-parties problem.

 Sun does warn users in FAQ that libCstd is not compliant to the  current C++ standard. Sun educates its users that use of libCstd where proper C++ Standard Library is needed is insane. See  workshop presentations by Roman Shaposhnik from Sun, where he writes:

• Sun Studio 12 : libCstd.so.1 not compliant with C++ Standard
• KDE4 needs a fully compliant Standard C++ Library
• KDE4 with libCstd.so.1 : Not Gonna Happen
• BOOST with libCstd.so.1 : Can Happen, but is insane

Sun does not really maintain libCstd, so further improvements to make it standard are unlikely to happen. However, Sun clearly supports FOSS-based toolset and already suggests users to go for it.

[strk]

Tai Meng from safe reports GEOS to build successfully on Solaris with Sun Studio Pro v12.