Stlport

Hi,
I am trying to build stlport 5.0 and have tried 4.6 with pretty much the same error.
Under:
SunOS 5.8/ Forte 8
$ make -f sunpro.mak
make: *** Warning: File `//net/bigspace/space/joseph/STLport-5.0-0125/src/../lib' has modification time in the future (2004-04-13 17:35:11 > 2004-04-13 17:34:08.039944769)
CC -mt w2 -library=no%Cstd -features=rtti -xildoff -I. -I//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport -O2 w2 -qoption ccfe -expand=1000 -PIC -ptr//net/bigspace/space/joseph/STLport-5.0-0125/src/../lib/obj/SUN/ReleaseD dll_main.cpp -c -o //net/bigspace/space/joseph/STLport-5.0-0125/src/../lib/obj/SUN/ReleaseD/dll_main.o
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/config/stl_sunpro.h", line 161: Warning: There are two consecutive underbars in "__mbstate_t".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/config/stl_sunpro.h", line 165: Warning: There are two consecutive underbars in "__filler".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_config.h", line 513: Warning: There are two consecutive underbars in "__std_alias".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/type_manips.h", line 23: Warning: There are two consecutive underbars in "__true_type".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/type_manips.h", line 24: Warning: There are two consecutive underbars in "__false_type".
Lots more of these warnings then
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_move_construct_fwk.h", line 70: Error: Empty declaration (probably an extra semicolon).
I remove the semicolon and then get
$ make -f sunpro.mak 2>&1 | grep -i error
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/debug/_debug.h", line 109: Warning: There are two consecutive underbars in "__error_ind".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 37: Warning: There are two consecutive underbars in "__stl_throw_range_error".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 37: Warning: There are two consecutive underbars in "__msg".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 38: Warning: There are two consecutive underbars in "__stl_throw_out_of_range".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 39: Warning: There are two consecutive underbars in "__stl_throw_length_error".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 40: Warning: There are two consecutive underbars in "__stl_throw_invalid_argument".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/_range_errors.h", line 41: Warning: There are two consecutive underbars in "__stl_throw_overflow_error".
"//net/bigspace/space/joseph/STLport-5.0-0125/src/../stlport/stl/pointers/_vector.c", line 66: Error: "_STL::vector<_STL::_Alloc>::operator=(const _STL::vector<void*, _STL::_Alloc>&)" was previously declared "_STL::vector<_STL::_Alloc>::operator=(const _STL::vector<void*, _STL::_Alloc>&)".
1 Error(s) and 376 Warning(s) detected.
make: *** [/net/bigspace/space/joseph/STLport-5.0-0125/src/../lib/obj/SUN/ReleaseD/dll_main.o] Error 1
Looks like a namespace error. Anyone successfully compiled this or a resonably new version of stlport?
Thanks,
Joe

Warning are just warnings. Code compiles to a binary if no errors are reported.
By default, you get warnings about constructs that are dangerous or that might not behave the way you intend. With w you get additional warnings. With w2, you get still more warnings that relate to portability issues, such as double underscores in identifiers.
If you build your own replacement for the C++ standard library, you must compile and link using -library=no%Cstd so that you don't mix parts of the default libCstd with your code. You can't have two versions of the standard library in one program.
Library libCrun contains helper routines needed by the Sun C++ compiler. Among other things, it includes routines for exception handling, typeid, operator new and delete. Every program compiled by Sun C++ must link with libCrun, because the compiler generates code to call these routines, and expects them to have specific behavior.
As a consequence, a replacement standard library must not provide any of the routines in libCrun, or replace headers associated with libCrun. Refer to the C++ Users Guide chapter on replacing the standard library for full details.
But if you use the STLport that comes with the compiler, you don't have to worry about any of these issues. We have taken care of adjusting STLport to work with our compiler and runtime system. All you need to do is add the option -library=stlport4 to every CC command line.
You should also consider upgrading to Sun Studio 11. The license for all uses is free, so there is no cost or obligation in upgrading.
http://developers.sun.com/sunstudio/

Similar Messages

12.3 and 12.4 beta. Cannot change the size of the ostream buffer with stlport.

The following program does not work as expected when compiled with -library=stlport4
#include <iostream>
using namespace std;
int main(int argc, char **argv) {
    cout.rdbuf()->pubsetbuf(new char[20*1024+1], 20*1024+1);
    cout.sync_with_stdio(false);
    for(int i=0; i!=50000; ++i)
        cout << i;
CC t.cc -library=stlport4 && truss -t write ./a.out > /dev/null
will show that it uses buffer-size of 4096
The same with 12.4.
This example will work if we exchange the order of the two cout... lines.
Without library=stlport4 it works fine.

Yes, that looks like a bug in STLport. I have filed bug 18810043 for you. If you have an Oracle Solaris Studio service contract with Oracle, you can request a fix.
The workaround is simple: move the sync_with_stdio call to the top of main.
In fact, the effect of calling sync_with-stdio after any I/O operation can vary among implementations, so doing the call first is better programming practice anyway.

How to build applications with a non standard stlport

Hi,
I have a separate compiled version of stlport that I am supposed to use to build my application. In other words, I do not want to use the stlport that comes with the Sun compiler. I am aware of using -library=stlport4 when I use the default stlport that comes with the compiler.
What flags/options should I use when I have my own stlport (libstlport_sunpro.so) library?
I am using Sun C++ 5.6 2004/07/15 on SunOS 5.8.
Pls help.
Thanks
Edited by: Sreeni_dd on Jul 23, 2009 12:50 PM

Details are in the C++ Users Guide, section 12.7 "Replacing the C++ Standard Library". Here is a summary.
1. Add the option -library=no%Cstd to disable both libCstd and STLport.
2. Add a -I option that points to the include directory for the stlport headers you want to use. (Do NOT use the headers in the compiler installation.) Example:
CC -library=no%Cstd -I/path/to/stlport/include -I/project1 -I/project2 ... If the compiler doesn't always find the headers, put the -I stlport option at the end of the other -I options, preceded by a -I- (dash eye dash) option. Example:
CC -library=no%Cstd -I/project1 -I/project2 -I- -I/path/to/stlport/include ... This procedure is not optimal, since you would like to search STLport headers before searching other headers. use the -I- option only if needed.
If you have file name conflicts with the STLport header files, you will need to add a set of symbolic links *.SUNWCCh as described in the C++ Users Guide.
3. For link commands, add a -L option pointing to the directory where the compiled STLport library is located. Assuming this library is called libstlport.so, also add the option -lstlport. Linking a static libstlport.a is not recommended if your program uses any shared libraries. Example:
CC -o myprog *.o -L/path/to/stlport/lib -lstlport

Workshop 6 Bug with STLport hash_map operator []

Using hash_map<string, string>:operator[] in a debug build crashes; in release, it doesn't. This must be a compiler bug, yes? Here's how to reproduce it.
<PRE>
[valhalla:~/test] $ cat t.c
#include <string>
#include <hash_map>
using namespace std;
main()
hash_map<string, string> m;
m["stl"] = "port";
string s = m["stl"];
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
Bus Error (core dumped)
[valhalla:~/test] $ dbx -q a.out core
core file header read successfully
program terminated by signal BUS (invalid address alignment)
Current function is STL::_stl_delete
99 inline void STLPCALL __stl_delete(void* __p) { ::operator delete(__p); }
(dbx) where
[1] freeunlocked(0xffbee657, 0xff23a000, 0xffbee657, 0xff23a000, 0x237e8, 0xff1c291c), at 0xff1c2974
[2] free(0xffbee657, 0xffbee5d4, 0xffbee658, 0xffbee5e2, 0xffbee5e1, 0xff19bb88), at 0xff1c2924
[3] operator delete(0xffbee657, 0xffbee658, 0xffbee657, 0xff37e540, 0x13bb0, 0x1ee00), at 0xff3636f8
=>[4] STL::_stl_delete(__p = 0xffbee657), line 99 in "new"
[5] STL::_node_alloc<true,0>::deallocate(__p = 0xffbee657, __n = 4347225U), line 253 in "_alloc.h"
[6] STL::allocator<char>::deallocate(this = 0xffbee5b0, _p = 0xffbee657 "", __n = 4347225U), line 360 in "_alloc.h"
[7] STL::STLP_alloc_proxy<char*,char,_STL::allocator<char> >::deallocate(this = 0xffbee5b0, __p = 0xffbee657 "", __n = 4347225U), line 506 in "_alloc.h"
[8] STL::String_base<char,_STL::allocator<char> >::_M_deallocate_block(this = 0xffbee5a8), line 124 in "_string.h"
[9] STL::String_base<char,_STL::allocator<char> >::~_String_base(this = 0xffbee5a8), line 135 in "_string.h"
[10] STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string(this = 0xffbee5a8), line 302 in "_string.h"
[11] STL::hashmap<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::hash<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::equal_to<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::allocator<_STL::pair<const STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > > > >::operator[](this = 0xffbee680, __key = CLASS), line 186 in "_hash_map.h"
[12] main(), line 8 in "t.c"
(dbx) exit
[valhalla:~/test] $ exit
exit
[valhalla:~/test] $ which CC
/apps/SUNWspro64/bin/CC
[valhalla:~/test] $ CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-09 2002/07/08
[valhalla:~/test] $ uname -a
SunOS valhalla 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Blade-100
</PRE>
STLport places all of its classes in its own _STL namespace, so there is no concern for name collision with std types that come with the Sun compiler.
Any ideas?
Regards,
Jason

I found out this is compiler bug with Forte 6 that ocurrs when inlining is enabled and temporaries are used in conditional expressions with the ?: operator, e.g.,
[valhalla:~/test] $ cat tt.c
#include <iostream>
#include <stdlib.h>
using namespace std;
struct X {
X() { cout << "X ctor" << endl; }
~X() { cout << "X dtor" << endl; }
int foo() { return 1; }
struct Y {
Y() { cout << "Y ctor" << endl; }
~Y() { cout << "Y dtor" << endl; }
int foo() { return 1; }
inline int foo(int i)
return i ?
X().foo() :
Y().foo() ;
main(int, char **argv)
return foo(atoi(argv[1]));
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC tt.c
[valhalla:~/test] $ a.out 1
X ctor
Y dtor
X dtor
[valhalla:~/test] $ g++ tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor

STLPort compile error V4.0

I have encountered the following error when I tried compiling the STLPort release 4.0 in new Sun Solaris compiler 6 update [Sun WorkShop 6 update 1 C++ 5.2 2000/09/11].
CC -mt -library=%none,Crun -template=wholeclass -I. -I/usr/local/src/STLport/STLport-4.0/src/../stlport -I/usr/local/src/STLport/STLport-4.0/src/../stlport/SC5 -D__SGI_STL_OWN_IOSTREAMS -g -D__STL_DEBUG complex_io.cpp -c -o obj/SUN/DebugSTL/complex_io.o
>> Assertion: (../links/tmplmatchargs.cc, line 153)
while processing /usr/local/src/STLport/STLport-4.0/src/../stlport/stl/_numeric_facets.c at line 0.
*** Error code 1
clearmake: Error: Build script failed for "obj/SUN/DebugSTL/complex_io.o"
Which I managed to compile successfully in solaris 4.2 [WorkShop Compilers 4.2 16 Jun 1998 C++ 4.2 patch 104631-07]
Can you please help me with this probelm.
Mag

I've also had this problem. This was a while back and at the time when I posted on the STLport discussion forum, it was suggested that one of the newer betas of STLport fixed the problem... I didn't try it because I wasn't in the mood to mess with beta stuff, but it may be released now (don't think so though). Check the discussion forums at www.sltport.org.

Overloading ambiguity when compile with stlport

I am trying to compile code with sun compiler 5.3 with stlport 4.5.3 with sun standard iostream.
Got the following error. Is this a bug in compiler ?
"/opt/local/STLport-4.5.3/stlport/stl/_vector.c", line 76: Error: Overloading ambiguity between "_STL::uninitialized_fill_n<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)" and "std::uninitialized_fill_n<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)".
"/opt/local/STLport-4.5.3/stlport/stl/_vector.h", line 460: Where: While instantiating "_STL::vector<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>, _STL::allocator<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>>::_M_fill_insert(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)".
"/opt/local/STLport-4.5.3/stlport/stl/_vector.h", line 460: Where: Instantiated from non-template code.

It's impossible to say whether the problem is in your code, the compiler, or in the STLport files without seeing the source code that you are trying to compile. Can you post a small example that illustrates the problem?
But we do not support STLport with C++ 5.3. If you have problems with that combination, you are on your own. If you can identify a compiler bug, we can try to fix it, but C++ 5.3 has been declared End Of Life, and only limited support is available.
Our recent compilers include a supported version of STLport. The current release is Sun Studio 10, but Studio 11 will be released within two weeks. Watch this space for details.
http://www.sun.com/software/products/studio/index.xml

SunStudio 9 and modified STLport 4.5

ok folks,
my development team uses a modified version of STLport ( we have made some usability enhancements to <rope> and pthread.h and pthread.c) but we are having a really tough time compiling it using the SunStudio 9 compiler. When we contacted the sun support people they said we would have to "rename" the standard headers that STLport provides to have a weird extension (e.g. iostream.SUNWcch?). However, even when we tried the workaround, we still ended up with weird compiler errors. NB: I am also compiling this same code on HPUX (using aCC), IBM (using VA7), linux(g++), and win32 (vc6sp6) .... I have no idea why SS9 will not allow you to override the compiler provided c++ standard headers. In the end, STLport (again, not the one bundled with SS9) includes the compiler c++ headers, so why all this fuss about renaming headers?
It would help if I could here other people's opinions on how they solved this problem (ie if they have modified STLport directly and are trying to compile it into a library)

We support the version of STLport that we ship with the compiler. We also allow complete replacement of the C++ standard library. Be we do not support modification of what we ship with the compiler.
If you modify or attempt to override the headers in the supplied STLport, the headers will no longer match the libstlport supplied with the compiler, which is linked automatically when you use the -library=stlport4 option. If you don't get link-time failures, you may get run-time failures.
Instructions for replacing the C++ standard library are in the C++ User's Guide, section 12.7 "Replacing the C++ Standard Library". To find the User's Guide, point your browser to <install-dir>/SUNWspro/docs/index.html and follow the link. By default, <install-dir> is /opt. Or you can find the manual at docs.sun.com.

STLPort 5.0.2 on Solaris 8

I am using Sun WorkShop 6 update 2 C++ 5.3 2001/05/15 compiler to configure STLport 5.0.2 on Solaris 8.
I am getting following errors.
"../../stlport/stl/_cmath.h", line 229: Error: fabs is not a member of file level.
Any clues???
Just to cross check that after ignoring this error everything get passed I commented this line and STLport library get created successfully. But when i linkedthat library with my sample application, sample application binary gets created successfully but while executing binary it get hangs even sample program printing Hello World will get hanged.
Any hints why this is happening???
thanks in advanced

Thanks paul, it worked and now am able to build the
STLport 5.0.2 library on Solaris 8 with Sun WorkShop
6 update 2 C++ 5.3 2001/05/15 compiler.
Now I am linking this library with my sample
application, it is getting linked successfully but my
application binary get hanged.... I am not getting
why this binary is getting hanged however while
compiling and linking it is not throwing any errors
or warnings????
-NitinYou can use truss <programname> or truss -p <pid> to look what's happening.
I've met that problem before, it's because I use .so file and put it to different path, so it hangs there.

Confused about warnings in STLport

Hi,
I'm using C++5.7:
% CC -V
CC: Sun C++ 5.7 Patch 117830-08 2006/07/12
I'm trying to compile a rather big code base using increased warning level and turning warnings into errors.
I'm having trouble with STLport's fstream include file (using STLport that ships with the compiler):
/opt/tools/SunStudio10/SUNWspro/bin/CC -g -mt -KPIC -library=%none,stlport4 +w -errtags -erroff=notemsource,unknownpragma -xwe -c Config.cc
"/opt/tools/SunStudio10/SUNWspro/prod/include/CC/stlport4/stl/_fstream.h", line 566: Warning, hidef: std::ifstream::rdbuf hides the function std::ios::rdbuf(std::streambuf *).
"Config.cc", line 253: Where, temwhilespec: While specializing "std::ifstream ".
"Config.cc", line 253: Where, temspecend: Specialized in non-template code.
Reading some earlier posts on this forum (e.g. http://forum.java.sun.com/thread.jspa?forumID=850&threadID=5070415), I was under the impression that the flag -xwe would suppress warnings coming from system headers (although the documentation about this option makes no mention of it).
Does this exclude STLport headers?
Also according to the above mentioned post, bug number 6197919 had been filed in order to get the appropriate behaviour when using -errwarn flag.
But I run into the same issue:
/opt/tools/SunStudio10/SUNWspro/bin/CC -g -mt -KPIC -library=%none,stlport4 -errtags -erroff=notemsource,unknownpragma -errwarn -c Config.cc
"/opt/tools/SunStudio10/SUNWspro/prod/include/CC/stlport4/stl/_fstream.h", line 566: Warning, hidef: std::ifstream::rdbuf hides the function std::ios::rdbuf(std::streambuf *).
"Config.cc", line 253: Where, temwhilespec: While specializing "std::ifstream ".
"Config.cc", line 253: Where, temspecend: Specialized in non-template code.
I don't want to ignore the error tag "hidef" as I did find user code doing real mistakes with name hiding.
Hopefully I missed something...
Cheers,
Bertrand.

This particular warning creates a special problem, because the C++ standard defines the iostream classes in such a way that an overload of rdbuf is hidden in a derived class. Over time, we have found and suppressed warnings like these that come from system headers.
A fix for this warning from stlport is in the next release, Sun Studio 12, which should be available Monday June 4.
If you have a service contract with Sun, you can request that this fix be backported to earlier compilers. The bug number is 6422467.
The only workarounds I can suggest are to disable the warning, don't use +w, or don't convert warnings to errors.

Supporting STLport in TTClasses

Hi!
How about supporting STLport in TTClasses in next version?

We had this happen when we added a new dimension to an existing application that already contained supporting detail. This supporting detail became abandoned (for lack of a better term) on the backend because it did not have a valid intersection after the new dimension was added. Yet, it still showed up in the webform. The supporting detail was red and it could not be deleted from the front-end via the webform. Being leary of writing a back-end sql update to delete this supporting detail, we handled it from the front-end using the Administration>Manage>Copy Data functionality within Planning. We simply picked a source intersection that contained no supporting detail (ie - from a future year) and copied it to the target intersection that contained the supporting detail in red. This cleared the supporting detail and we were then able to add new supporting detail without issue. We were fortunate that supporting detail was not heavily used by our end-users so it did not take too long to clear all the affected intersections.
Not sure if this will work in your case but I hope this helps.
Regards,
Craig

Occi doesn't support STLPORT

When I link occi program with STLPORT, error happens:
testocci.obj : error LNK2001: unresolved external symbol "public: virtual class _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> > __thiscall oracle::occi::SQLException::getMessage(void)const " (?getMessage@SQLExcep
tion@occi@oracle@@UBE?AV?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@XZ)
Release/testocci.exe : fatal error LNK1120: 1 unresolved externals

Hi,
i'm currently working on occi (which has such a great api than jdbc), see how i could intergate it in my db access layer in addition of the odbc one, but as we use stlport, we just can't get any success with it.
Is there any chance that Oracle will provide libraries compiled with stlport which is quite widely used today ? Maybe is there someone we could request that ?
Thank you in advance.
Adrien

Suggestions on compiling STLPort?

About two weeks ago, I posted a problem using the STLPort4 library where a segmentation fault happens down in STLPatomic_exchange. I am still encountering the problem intermittently.
I would like to compile the latest stable release from www.stlport.com so that I better track down the problem.
Are there any special compile commands needed to get the STLPort to compile under C++ 5.4?
The compiler command for including stlport "-library=stlport4" appears to be special for the library, why is that?

The following code has been shown to reproduce my SEGV issue in stlport's STLPatomic_exchange. Before compiling and running:
1. This problem could take one to many minutes to occur
2. Make sure that your platform has nobody else using it because the app will drive your CPU to 100%
3. Please don't make fun of my Makefile
Good luck and I hope you have the same "success" that I had.
### Makefile Start
PLATFORM :sh= uname -p | sed s/i386/x86/
OSVARIANT=$(PLATFORM)-SunOS
#### Compiler and tool definitions shared by all build targets #####
CCC=CC
BASICOPTS=
CCFLAGS= -g -mt -library=stlport4 -staticlib=stlport4 -misalign
CCADMIN=CCadmin
## Target: GCNServer
CPPFLAGS = -I/usr/include -I/usr/include/sys
OBJS = stlproblem.o
SYSLIBS = -lpthread -lm -lsocket -lnsl -lposix4
LDLIBS = $(SYSLIBS)
# Link or archive
stlproblem: $(OBJS)
     $(LINK.cc) -o stlproblem $(OBJS) $(LDLIBS)
# Compile source files into .o filess
stlproblem.o: stlproblem.cpp
     $(COMPILE.cc) -o $@ stlproblem.cpp
#### Clean target deletes all generated files ####
clean::
     $(RM) ./stlproblem ./stlproblem.o
     $(CCADMIN) -clean
# Create the target directory (if needed)
obj:
# Enable dependency checking
.KEEP_STATE:
### Makefile end
// stlproblem.cpp code start
This source file contains a system of n threaded objects that use a common object
table in order to access the other threaded objects. As the system runs, x
number of messages are passed randomly between these threaded objects. In order
to access the object pointer for a message recipient, the common
ObjectTable::GetObjectPointer method is used. In this call, STL will SEGV in
the _STLP_atomic_exchange. This problem occurs on our SUN 280R servers (1 CPU)
in Solaris 9. Our compiler version is CC: Forte Developer 7 C++ 5.4 2002/03/09.
#include "stdlib.h"
#include "stdio.h"
#include "math.h"
#include "pthread.h"
#include "semaphore.h"
#include <iostream>
#include <list>
#include <string>
#include <map>
#define THREAD_COUNT   100
#define MESSAGE_COUNT 1000
using namespace std;
// shared table to hold the objects
class ObjectTable
public:
    ObjectTable();
    ~ObjectTable();
    void* GetObjectPointer(std::string Name);
    std::map<std::string, void*> m_table;
ObjectTable::ObjectTable(void)
ObjectTable::~ObjectTable(void)
void* ObjectTable::GetObjectPointer(std::string Name)
    std::string object_name;
    std::string instance;
    std::map<std::string, void*>::iterator iter;
    void *rtnval = NULL;
    // this is where STLPort is expected to crash, so play with std::string operations
    // iterate to slow this method down and get more than one thread in here
    iter = m_table.begin();
    for(int i=0; i<m_table.size(); i++)
        object_name = (*iter).first;
        // the following line appears to be the main culprit even though it does nothing useful
        instance = object_name.substr(0, object_name.find("e")+1);
        if(object_name == Name)
            rtnval = m_table[object_name];
        iter++;
    return rtnval;
// global declaration of the table that all objects can reference
ObjectTable *gObjectTable = NULL;
// message payload class
class Message
public:
    Message(std::string Text);
    ~Message(void);
    std::string m_messageText;
Message::Message(std::string Text)
    m_messageText = Text;
Message::~Message(void)
// the main living object class
class LivingObject
public:
    LivingObject(std::string ObjectName);
    ~LivingObject(void);
    void HandleMessages(void);
    void QueueMessage(Message* pMsg);
    pthread_mutex_t m_criticalSectionMutex;
    pthread_cond_t m_messageEventCondition;
    pthread_mutex_t m_messageEventMutex;
    std::list<Message*> m_messageList;
    std::string m_myName;
LivingObject::LivingObject(std::string ObjectName)
    pthread_mutex_init(&m_criticalSectionMutex, NULL);
    pthread_cond_init(&m_messageEventCondition, NULL);
    pthread_mutex_init(&m_messageEventMutex, NULL);
    m_messageList.clear();
    m_myName = ObjectName;
LivingObject::~LivingObject(void)
void LivingObject::HandleMessages(void)
    char buf[16];
    unsigned int seed = 4925;
    while(1)
        pthread_cond_wait(&m_messageEventCondition, &m_messageEventMutex);
        while(m_messageList.size() > 0)
            pthread_mutex_lock(&m_criticalSectionMutex);
            Message *p_msg = (Message*) m_messageList.front();
            m_messageList.pop_front();
            pthread_mutex_unlock(&m_criticalSectionMutex);
            LivingObject *p_object;
            do
                // pick a random object to send the message to (can't be ourselves)
                seed = rand_r(&seed);
                int object_number = (int) floor(((double)seed/(double)RAND_MAX) * THREAD_COUNT);
                sprintf(buf, "Instance%d", object_number);
                std::string object_name = buf;
                // Turn the following line on to show the message activity between threads
                // When the cout is active, it may delay the SEGV issue.
                //cout << m_myName << " is sending " << p_msg->m_messageText << " to " << object_name << endl;
                // the SEGV crash should occur in this call - gObjectTable is the global pointer
                p_object = (LivingObject*) gObjectTable->GetObjectPointer(object_name);
                if(p_object != this && p_object != NULL)
                    p_object->QueueMessage(p_msg);
            } while(p_object == this);
void LivingObject::QueueMessage(Message *pMsg)
    // protect the message list since it is read-write
    pthread_mutex_lock(&m_criticalSectionMutex);
    m_messageList.push_back(pMsg);
    pthread_cond_signal(&m_messageEventCondition);
    pthread_mutex_unlock(&m_criticalSectionMutex);
// thread entry point for the LivingObject class
extern "C" void* LivingObjectThread(void* param)
    std::string object_name = (char*) param;
    LivingObject *alive_object = new LivingObject(object_name);
    cout << object_name << " is alive!" << endl;
    gObjectTable->m_table[object_name] = (void*) alive_object;
    // HandleMessages() will block indefinitely...
    alive_object->HandleMessages();
    // ...and we never get here
    return 0;
int main(int argc, char* argv[])
    char *name_buf;
    gObjectTable = new ObjectTable();
    // create lots of threads
    pthread_t tid;
    for(int i=0; i<THREAD_COUNT; i++)
        name_buf = new char[16];
        sprintf(name_buf, "Instance%d", i);
        pthread_create(&tid, NULL, LivingObjectThread, (void*)name_buf);
    // Get the ball rolling - effectively these "messages" will bounce around
    // through all of the object threads just created. the idea is that
    // eventually two threads will enter the ObjectTable::GetObjectPointer
    // at the same time and cause the STLPort crash in _STLP_atomic_exchange().
    LivingObject *instance0 = NULL;
    do
        instance0 = (LivingObject*) gObjectTable->GetObjectPointer((std::string)"Instance0");
    } while(instance0 == NULL);
    // create lots of messages
    char message_buf[64];
    for(int i=0; i<MESSAGE_COUNT; i++)
        sprintf(message_buf, "Message Number %d", i+1);
        Message *msg = new Message(message_buf);
        instance0->QueueMessage(msg);
    // block the app from exiting (CTRL-C is the only way out)
    sem_t never_exit_event;
    sem_init(&never_exit_event, 0, 0);
    sem_wait(&never_exit_event);
    return 0;
// stlproblem.cpp code end

Any workaround to make OCCI works with stlport?

Dear all,
after read num of threads in the forum, I found myself in a popular problem of OCCI with stlport, is there any workaround for it (except: fallback to use OCI or drop stlport)?
any 3rd party library or .. anything suggested?
Thank you very very much
Reggie

For Solaris or Linux?
Thanks,
Shankar

Intresting segv:studio12update1 core dump in stlport 4 startup:mixing C&C++

Hi
I am getting core dump below is the stack trace:
(dbx) where
current thread: t@1
=>[1] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff4b3d0bf0, 0xffffffff7fffe790, 0x4c8, 0xffffffff6971f128, 0x400, 0xffffffff69711e68), at 0xffffffff69592200
[2] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::pubimbue(0xffffffff695921a0, 0xffffffff4b3d0bf0, 0xffffffff7fffe790, 0xffffffff6971a938, 0x0, 0xffffffff7fffe6d0), at 0xffffffff6956d4e8
[3] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7fffe798, 0xffffffff6971fbd0, 0xffffffff7fffe790, 0xffffffff69711e68, 0x13da94, 0x400), at 0xffffffff6957284c
[4] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::init(0xffffffff6971fbd0, 0xffffffff4b3d0bf0, 0x448, 0xffffffff69711e68, 0x19f4c4, 0x400), at 0xffffffff69572a0c
[5] std::basic_ostream<wchar_t,std::char_traits<wchar_t> >::basic_ostream(0xffffffff6971fbc8, 0xffffffff4b3d0bf0, 0xc0, 0x185fec, 0x0, 0xffffffff69711e68), at 0xffffffff6958becc
[6] std::__Wide_Init::__Wide_Init(0xffffffff4b3ceec0, 0xffffffff4b3d0bf0, 0xffffffff4b3d0c90, 0xffffffff4b3c27d0, 0xffffffff6971fd38, 0xe000), at 0xffffffff4b21444c
---- hidden frames, use 'where -h' to see them all ----
[8] __Cimpl::cplus_init(0x1, 0xffffffff4de0dd60, 0xffffffff4de0dd68, 0x0, 0x1044a4, 0xffffffff4b3cf460), at 0xffffffff4dd08660
[9] 0xffffffff4b235ae8(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff7f402400), at 0xffffffff4b235ae8
[10] call_init(0x1, 0x1, 0xffffffff4b235a10, 0xffffffff68a007b8, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[11] setup(0xc7, 0x28, 0xc10000, 0xa000000, 0xffffffff61a01b08, 0x100000), at 0xffffffff7f6113b4
[12] _setup(0x6ffffff9, 0xb00, 0xffffffff7f62ae5c, 0x100000040, 0x0, 0xffffffff7ffff158), at 0xffffffff7f620554
[13] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60511c
Some important notes I am mixing C & C++
wrap is the C interface so when I link application I am explicitly linking libC & libstlport.so
-L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport
-L/usr/lib/64
-lstlport
-lCrun
I am compiling my application like this :
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c DBAbs.cpp -o /export/home/frtbld/TMPOBJ/DBAbs.o
Generating MyDb.o file from MyDb.cpp file ...
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c MyDb.cpp -o /export/home/frtbld/TMPOBJ/MyDb.o
Generating wrap.o file from wrap.cpp file ...
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c wrap.cpp -o /export/home/frtbld/TMPOBJ/wrap.o
ar *.o -o /export/home/frtbld/libcbin/LIB_BDBManager.a
/export/home/tuxedo/bea/tuxedo10gR3/bin/buildclient -o /export/home/frtbld/TMPBIN/CompilerPP -f-L/export/home/oracle/OraHome/lib -f-lclntsh \
-f /export/home/frtbld/TMPOBJ/CompilerMainPP.o \
-f /export/home/frtbld/TMPOBJ/CompilerDataBasePP1.o \
-f /export/home/frtbld/TMPOBJ/CompilerDataBasePP2.o \
-f /export/home/frtbld/TMPOBJ/utilityPP.o \
-f "-L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport -L/export/home/frtbld/3rdparty/lib/bdblib -L/export/home/frtbld/3rdparty/lib/acelib -ldb_cxx-4.7 -lACE /export/home/frtbld/libcbin/LIB_DataBase.a /export/home/frtbld/libcbin/LIB_FileManager.a /export/home/frtbld/libcbin/LIB_Log.a /export/home/frtbld/libcbin/LIB_SHMManager.a /export/home/frtbld/libcbin/LIB_Expression.a /export/home/frtbld/libcbin/LIB_Timing.a /export/home/frtbld/libcbin/LIB_MMFManager.a /export/home/frtbld/libcbin/LIB_LicManager.a /export/home/frtbld/libcbin/LIB_InterProcComm.a /export/home/frtbld/libcbin/LIB_BDBManager.a /export/home/frtbld/libcbin/LIB_RatingPPMMFManager.a -L/usr/lib/hpux32/ -L/usr/local/lib/hpux32 -L/lib/hpux32 -L/export/home/frtbld/3rdparty/lib/ssllib -lcrypto -lz -lm -L/usr/lib/64 -L/opt/sunstudio12.1/lib/stlport4/v9 -lCrun "
Regards
Anand Rathi

Hi Thanks for your help
I changed the linking process to use CC
but still its same .....
and i can also see that its invoking __Cimpl::cplus_init
also i have an doubt about 64bit and std::__Wide_Init::__Wide_Init
weather issue is with wide character 64 bit ?
Now the command is
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -mt -I/export/home/tuxedo/bea/tuxedo10gR3/include -o /export/home/frtbld/TMPBIN/CompilerPP -L/export/home/tuxedo/bea/tuxedo10gR3/lib -xarch=v9 -L/export/home/oracle/OraHome/lib -lclntsh /export/home/frtbld/TMPOBJ/CompilerMainPP.o /export/home/frtbld/TMPOBJ/CompilerDataBasePP1.o /export/home/frtbld/TMPOBJ/CompilerDataBasePP2.o /export/home/frtbld/TMPOBJ/utilityPP.o -L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport -L/export/home/frtbld/3rdparty/lib/bdblib -L/export/home/frtbld/3rdparty/lib/acelib -ldb_cxx-4.7 -lACE /export/home/frtbld/libcbin/LIB_DataBase.a /export/home/frtbld/libcbin/LIB_FileManager.a /export/home/frtbld/libcbin/LIB_Log.a /export/home/frtbld/libcbin/LIB_SHMManager.a /export/home/frtbld/libcbin/LIB_Expression.a /export/home/frtbld/libcbin/LIB_Timing.a /export/home/frtbld/libcbin/LIB_MMFManager.a /export/home/frtbld/libcbin/LIB_LicManager.a /export/home/frtbld/libcbin/LIB_InterProcComm.a /export/home/frtbld/libcbin/LIB_BDBManager.a /export/home/frtbld/libcbin/LIB_RatingPPMMFManager.a -L/usr/lib/hpux32/ -L/usr/local/lib/hpux32 -L/lib/hpux32 -L/export/home/frtbld/3rdparty/lib/ssllib -lcrypto -lz -lm -L/usr/lib/64 -L/opt/sunstudio12.1/lib/stlport4/v9 -lCrun -ltux -lbuft -lfml -lfml32 -lengine -R/usr/lib/lwp -lpthread -lposix4 -lsocket -lnsl -lm -lnsl -lsocket
t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
0xffffffff7e192200: imbue+0x0060: ldx [%o0], %o1
(dbx) where
current thread: t@1
=>[1] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7acd0bf0, 0xffffffff7fffe4d0, 0x4c8, 0xffffffff7e31f128, 0x400, 0xffffffff7e311e68), at 0xffffffff7e192200
[2] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::pubimbue(0xffffffff7e1921a0, 0xffffffff7acd0bf0, 0xffffffff7fffe4d0, 0xffffffff7e31a938, 0x13da94, 0xffffffff7fffe410), at 0xffffffff7e16d4e8
[3] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7fffe4d8, 0xffffffff7e31fbd0, 0xffffffff7fffe4d0, 0xffffffff7e311e68, 0x13da94, 0x400), at 0xffffffff7e17284c
[4] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::init(0xffffffff7e31fbd0, 0xffffffff7acd0bf0, 0x448, 0xffffffff7e311e68, 0x19f4c4, 0x400), at 0xffffffff7e172a0c
[5] std::basic_ostream<wchar_t,std::char_traits<wchar_t> >::basic_ostream(0xffffffff7e31fbc8, 0xffffffff7acd0bf0, 0xc0, 0x185fec, 0x0, 0xffffffff7e311e68), at 0xffffffff7e18becc
[6] std::__Wide_Init::__Wide_Init(0xffffffff7acceec0, 0xffffffff7acd0bf0, 0xffffffff7acd0c90, 0xffffffff7acc27d0, 0xffffffff7e31fd38, 0xe000), at 0xffffffff7ab1444c
---- hidden frames, use 'where -h' to see them all ----
[8] __Cimpl::cplus_init(0x1, 0xffffffff7d00dd60, 0xffffffff7d00dd68, 0x0, 0x1044a4, 0xffffffff7accf460), at 0xffffffff7cf08660
[9] 0xffffffff7cf0a500(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff79702000), at 0xffffffff7cf0a500
[10] call_init(0x1, 0x3, 0xffffffff7cf0a428, 0xffffffff7f201530, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[11] elf_bndr(0xffffffff7f500718, 0xffffffff7cf016e0, 0xffffffff7ab35ab4, 0xffffffff7cf06610, 0xffffffff78d009e8, 0xffffffff7f72f6d8), at 0xffffffff7f61f060
[12] elf_rtbndr(0x590000, 0x1001d3538, 0x0, 0xffffffff7ab35ab4, 0x0, 0x0), at 0xffffffff7f60514c
[13] 0x0(0xffffffff7acc7e28, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x0
[14] 0xffffffff7ab35ab4(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff79702000), at 0xffffffff7ab35ab4
[15] call_init(0x1, 0x1, 0xffffffff7ab35a10, 0xffffffff7a900030, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[16] setup(0x0, 0x27, 0xc10000, 0xa000000, 0xffffffff78d01780, 0x100000), at 0xffffffff7f6113b4
[17] _setup(0x6ffffff9, 0xb00, 0xffffffff7f62ae5c, 0x100000040, 0x0, 0xffffffff7ffff288), at 0xffffffff7f620554
[18] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60511c
Edited by: anandprathi on Aug 12, 2009 9:48 AM
Edited by: anandprathi on Aug 12, 2009 9:52 AM

Stlport problem with streambuf EOF

Hi
stlport4 does not seem to fail correctly with the following example on
SunOS sun 5.8 Generic_117350-27 sun4u sparc SUNW,Sun-Fire-480R
with
CC: Sun C++ 5.6 Patch 117549-03 2005/07/19
or
CC: Sun C++ 5.8 2005/10/13
CC test.cpp -library=stlport4
./a.out < test.cpp
#include <iostream>
#include <streambuf>
class obuf : public std::streambuf
protected:
        virtual int_type overflow (int_type c)
                std::cout << static_cast<char>(c);
                return EOF;
int main()
        obuf ofail;
        std::ostream ostrm( & ofail );
        ostrm << std::cin.rdbuf() << std::endl;
        return 0;
}Please clamage45, tell me I'm doing something wrong.
/Lars

Probably releated
The following code will hang when run on a filled filesystem.
CC test.cpp -library=stlport4
test.cpp
#include <iostream>
#include <fstream>
int main()
    std::ofstream ofs( "test.out" );
    std::ifstream ifs( "test.cpp" );
    if( ofs )
        ofs << ifs.rdbuf() << std::endl;
    std::cout << ofs.good() << ' ' << ofs.fail() << ' ' << ofs.bad() << std::end
l;
    return 0;
}

Stlport

Similar Messages

Maybe you are looking for