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.

Similar Messages

Stlport-compatible version of OCCI for Solaris x86_64

Hi,
Is there one? I noticed that 64-bit version of Instant Client for 64-bit Sparc includes libocci_stlport4.so starting from 10.2.0.3 release, however the file is absent from all x86_64 releases. Any ideas?
Regards,
Alex

Hi Alex,
It should be theoritically possible for oracle to release libocci_stlport4.so of solaris x86_64 architecture. I dont think its available yet. Please contact Oracle support and request for such a shared object. BTW, which oracle database version are you on?

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.

Compilation error while building boost 1_44_0 on Solaris (Sun Studio 10)

Hi All, I am trying to build boost version 1_44_0 on Solaris.The Solaris box has Sun Studio 10 installed.
The compiler details are
bash-2.05$ CC -V
CC: Sun C++ 5.7 2005/01/07
I am using the following command to build boost libraries
*bash-2.05$ bjam --build-dir=/export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost toolset=sun stage*
But i get the below compilation errors, not even one of the projects build
sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boo
st/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/fi
le_descriptor.o
Notice: The Early Access serial number will expire in -7 days.
In order to purchase the product, visit http://www.sun.com/forte/buy.html
or contact your Forte Tools reseller.
"libs/iostreams/src/file_descriptor.cpp", line 352: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 355: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 360: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 380: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 385: Error: Could not find boost:
:shared_ptr<boost::iostreams::detail::file_descriptor_impl>::shared_ptr(boost::i
ostreams::detail::file_descriptor_impl*) to initialize pimpl_.
"libs/iostreams/src/file_descriptor.cpp", line 393: Error: Using static_cast to
convert from boost::iostreams::file_descriptor_flags to boost::iostreams::detail
::file_descriptor_impl::flags not allowed.
6 Error(s) detected.
"CC" -library=stlport4 -xO4 -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DB
OOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o
"/export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boost/bin.v2/libs/
iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/file_descriptor.o
" "libs/iostreams/src/file_descriptor.cpp"
...failed sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build
-boost/boost/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threadin
g-multi/file_descriptor.o...
sun.compile.c++ /export/home/dfdev/Boost_1_44_0/boost_1_44_0/tmp/build-boost/boo
st/bin.v2/libs/iostreams/build/sun/release/stdlib-sun-stlport/threading-multi/ma
pped_file.o
Notice: The Early Access serial number will expire in -7 days.
In order to purchase the product, visit http://www.sun.com/forte/buy.html
or contact your Forte Tools reseller.
"./boost/type_traits/is_array.hpp", line 41: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 42: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 43: Error: Multiple declaration for boo
st::is_array.
"./boost/type_traits/is_array.hpp", line 44: Error: Multiple declaration for boo
st::is_array.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 95: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1> is dependent on
another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 95: Error: Partial s
pecialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 112: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 172: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2> is dependent on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 172: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 189: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 254: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3> is dependent on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 254: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 271: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 339: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3, boost::mpl::aux::P4> is dependent on another argument
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 339: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 357: Error: Partial
specialization parameter F is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 427: Error: The type
of specialized argument boost::mpl::aux::F<boost::mpl::aux::P1, boost::mpl::aux
::P2, boost::mpl::aux::P3, boost::mpl::aux::P4, boost::mpl::aux::P5> is dependen
t on another argument.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 427: Error: Partial
specialization parameter Tag is not used in the arguments.
"./boost/mpl/aux_/preprocessed/plain/full_lambda.hpp", line 445: Error: Partial
specialization parameter F is not used in the arguments.
"libs/iostreams/src/mapped_file.cpp", line 441: Error: Could not find boost::sha
red_ptr<boost::iostreams::detail::mapped_file_impl>::shared_ptr(boost::iostreams
::detail::mapped_file_impl*) to initialize pimpl_.
20 Error(s) detected.
Am i missing something? I will appreciate your input's.
Regards,
solarisneo

C++ 5.7 will not give good results building Boost.
Support for boost began with C++ 5.9 (Sun Studio 12), but you will get better results using the current release, Sun Studio 12 update 1, and better still with the upcoming release, Oracle Solaris Studio 12.2.

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.

Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh

I have found a way to get an assertion failure from the ccfe program that comes with the Solaris Studio 12.4 beta July refresh. The error that gets printed is:
>> Assertion:   (../lnk/funcsym.cc, line 1679)
    while processing text_woarchive.pre.cpp at line 0.
The problem occurs whilst compiling Boost 1.54. The original file in the distribution that causes it is libs/serialization/src/text_woarchive.cpp.
This problem can be reproduced by getting the pre-processed code I've put on http://pastebin.com/E9vxi2z7 and pasting it into a file called text_woarchive.pre.cpp. Then run:
CC -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
and you get the assertion failure.
Running:
CC '-#' -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
shows that the assertion is coming from ccfe.
In case you go back to the original Boost source code I should tell you that prior to generating the pre-processed source I changed:
#ifdef __SUNPRO_CC
to:
#if 0
in boost/archive/detail/register_archive.hpp. I did this because there was an error in the __SUNPRO_CC section and I wondered if that workaround code was no longer required with the more modern C++ compiler. Therefore, I cannot guarantee that the pre-processed source is 100% valid C++ code. However, even if it's not it would be nice to get a clear error message out of ccfe rather than an assertion failure.
In case it's relevant, I'm working on Oracle Solaris 10 1/13 s10x_u11wos_24a X86.

You mentioned in the other answer that you are testing with Boost 1.55. Are you testing this in C++11 mode?
Today I downloaded Boost 1.55 and did the following:
In both tools/build/v2/engine/build.sh and tools/build/v2/tools/sun.jam globally replace SUNWspro with SolarisStudio12.4-beta_jul14-solaris-x86
In tools/build/v2/tools/sun.jam replace:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
    : <cxxflags>-library=stlport4 <linkflags>-library=stlport4
with:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
    : <cxxflags>-std=c++11 <linkflags>-std=c++11
Note: This is just the quick way I found to con the Boost build system into using C++11 instead of STLport. The feature in the jam file still has stlport in its name, but that's only a name and the code is being built in C++11 mode.
In boost/math/special_functions/detail/lanczos_sse2.hpp change line 15 from:
#if defined(__GNUC__) || defined(__PGI)
to:
#if defined(__GNUC__) || defined(__PGI) || defined(__SUNPRO_CC)
Run:
./bootstrap.sh --without-libraries=context --without-libraries=coroutine --without-libraries=graph_parallel --without-libraries=log --without-libraries=mpi --without-libraries=python --without-libraries=test --without-icu
Run:
./b2 -j4 --layout=versioned --disable-icu address-model=64 threading=multi optimization=speed inlining=full
At this point the vast majority of the code builds, but does not link.
There are 3 problems:
The compilation problem with tuple that you've already fixed
A linker problem with finding std::string related symbols - maybe also related to the gcc header upgrade and now fixed?
Numerous compilation problems caused by boost/archive/detail/register_archive.hpp
For this last one the code in the #ifdef __SUNPRO_CC section of boost/archive/detail/register_archive.hpp does appear to be invalid, and leads to the errors:
"./boost/archive/detail/register_archive.hpp", line 45: Error: The function "adjust_counter" must have a prototype.
"./boost/archive/detail/register_archive.hpp", line 46: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 47: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 48: Error: An integer constant expression is required within the array subscript operator.
Even with Boost 1.55, attempts to fix this lead to the same ccfe assertion. Trying to use the #else part of the code as I described in the original post does, as does moving the line:
char adjust_counter(counter<0>);
so that it comes before the place where adjust_counter is used also then leads to the same assertion:
>> Assertion:   (../lnk/funcsym.cc, line 1679)
It's as though any change to boost/archive/detail/register_archive.hpp that fixes the basic code ordering issue lets ccfe get far enough to cause the assertion.
If there is somebody in your team looking at whether Boost 1.55 compiles with Solaris Studio 12.4 in C++11 mode then hopefully they can relate to what I'm seeing here. One key point is that they'll have had to edit the jam files to use C++11 mode.
The other thing is that any insights the person who has been trying to build Boost 1.55 has would be very useful. I know you don't want to get into officially supporting it, but maybe a blog post with any unofficial hints and tips on getting Boost to build in C++11 mode could be a way to share knowledge.

Poor performance of string::append on Solaris 10 with Sun Studio 10

I found string::append(size_type num, char ch) of libCstd consumes too much cpu time comparing with stlport. Anybody knows if this is a known issue on Solaris 10 and Sun Studio 10? Or if I need to use special build options to build with libCstd?
For example: a.c
#include <iostream>
#include <time.h>
using namespace std;
int main()
string ss;
for ( i=0; i<60000; i++)
ss.append(1, 'A');
cout << clock();
cout << endl;
return 0;
}Build with libCstd:
CC a.c -o a1
Build with stlport:
CC -library=%none -library=stlport4 a.c -o a2
a1 outputs: 10000
a2 outputs: 1900000
You can see how big different they have. I am sure their running environment is same.

I suspect this is due to a bug in libCstd that manifests itself by reallocating the string for each append. Compile and run the program below:
#include <string>
#include <new>
#include <stdlib.h>
int in_main;
void* operator new (size_t nbytes) throw (std::bad_alloc) {
if (in_main) printf ("operator new (%zu)\n", nbytes);
return malloc (nbytes);
void operator delete (void *p) throw () {
if (in_main) printf ("operator delete (%p)\n", p);
free (p);
int main () {
in_main = 1;
std::string ss;
for (int i = 0; i < 256; i++) {
printf ("append(1, 'A')\n");
ss.append (1, 'A');
in_main = 0;
}

Is it Solaris or Linux ?

Has anyone tried to build STLPort 4.5 on Linux with Sun Studio?
This package is incredibly complex, and riddled with #ifdef hell.
I don't blame the author for that ... it's taken a long time for the industry to settle on standards, and for bugs to disappear from compilers.
The first issue I'm facing is method STLport uses to detect the platform it's building for. It's actually checking multiple versions of sun studio, and not the platform itself.
I could use some suggestions on how best to solve this problem. I build STLport for both Solaris x86 and for SuSE Linux, for 64bit running on AMD hardware.
If STLport thinks it's compiling on Solaris, it starts including Sun-specific header files that don't exist on Linux.
Is there a preferred way to detect/distinguish the platforms?
ps., I don't give a darn about historic issues and keeping ancient compilers alive in this code; just how to move forward with the latest sun studio on both platforms.

You can report STLport issues here, or by filing a bug report at bugs.sun.com.
You get the best response and resolution if you have a service contract with Sun. You can get pre-release patches and updates, escalate issues that are important to you, and be kept informed of progress. For the free support here and at bugs.sun.com, we make no promises.
Later versions of STLport are not compatible with 4.5.3, which is why we have not updated the version that we ship. Because of the incompatibility, we are currenlty evaluating whether to ship a newer version of STLport, or ship some other library that promises to be more stable. That is, whatever new thing we ship will be incompatible, so we need not restrict our evaluations to STLport.
We have not yet reached a decision.
There is a fairly long delay between the compiler development process and what gets posted on the web site. I think the STLport bits for linux were not ready in time for the update currently on the web site. I'm looking into the situation and will let you know what I find out.

Guidance on solaris/c++

Hi all,
i know its not the group for me to post but still .. i thought i could get more information from this group rather. ..
I would like you to recommend some sites or books for the Solaris o/s on sun sparc and what is the best compiler for C++ for socket programming that anyone can recommend . Can i Use Richrard Stevens Unix network programming ???
advice pls..

Hi
This is taken from Solaris forum for Sun Studio C++
The default libCstd implementation of the C++ Standard Library is incomplete. As explained in the compiler docs, we continue to provide a version of this library that is source and binary compatible from compiler release to release. Fixing its deficiencies would break compatibility.
If you don't need compatibility with libCstd, STLport is a standard-conforming implementation of the C++ Standard Library , along with some popular extensions like hash_map and rope.
To compensate for some missing functionality, libCstd has some non-standard interfaces. If your code depends on these non-standard interfaces, it won't compile using STLport. If your code conforms to the interface defined by the C++ Standard, it will compile with STLport.
Most programmers find that they can just switch to STLport without problems.
As I noted above, an entire program, including shared libraries, must all use the same standard library implementation. You can't mix them. Binaries compiled without the -library=stlport4 option must be recompiled using that option.
Do you disagree with Sun support personal?
"You have run into a documented limitation of the default libCstd implementation of the C++ standard library. The default library is not a complete implementation, and In particular, the template "sort" member of list that takes a parameter is not available."
/Lars

Help with Install of Xerces-c 2.4.0 for Solaris

After having memory leak issues with Xerces-c 2.3.0 for Solaris 2.7
for CC 6.2 I have decided to update to at least 2.4. I have
downloaded the binary tarball and have installed it on my development
server, which runs Solaris 2.8. I do use CC 6.2 for my compiler. I
have reset all the environment variables in Korn shell that point to
the Xerces distribution.
When I try to compile the same piece of code that compiles fine under
Xerces 2.3 the compiler spits back the following errors compiling
against 2.4 regarding the XSerializeEngine.hpp :
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 541: Warning: Too many arguments in macro Assert.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 541: Error: No direct declarator preceding "(".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 541: Error: Use ";" to terminate declarations.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 546: Error: Use ";" to terminate declarations.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 652: Warning: Too many arguments in macro Assert.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 657: Warning: Too many arguments in macro Assert.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 663: Warning: Too many arguments in macro Assert.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 663: Error: No direct declarator preceding "(".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 664: Error: A declaration does not specify a tag or an
identifier.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 664: Error: Use ";" to terminate declarations.
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 664: Error: A declaration was expected instead of "{".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 665: Error: No direct declarator preceding "(".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 667: Error: "," expected instead of ")".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 670: Error: A declaration was expected instead of "}".
"/opt/local/software/xerces/xerces-c2_4_0-solaris_27-cc_62/include/xercesc/internal/XSerializeEngine.hpp",
line 702: Error: A declaration was expected instead of "}".
11 Error(s) and 4 Warning(s) detected.
gnu_make: *** [SchedUpdateSubscriber] Error 11
Any ideas on what I am doing wrong?
Thanks in advance.

I've always compiled xerces from the source code. Have used 2.4.0 and 2.5.0 this way with Sun One Studio 8 without any issues.
If you want to try compiling, I'd recommend going with the later release (more compiler tweaks and fixes) and the following build commands:-
% cd xerces-c-src_2_5_0
% export XERCESCROOT=`pwd`
% cd src/xercesc
% runConfigure -r pthread -p solaris
% export CXXFLAGS="-library=stlport4" - skip this line if you're not using stlport
% ./configure
% gmake
Hope that helps!

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

Logical interface in solaris 10

Hi there,
I need to configure logical interface in a solaris 10 3/05 server. After reading the Solaris 10 IP services manual, I am not quite sure what to do. All the examples and explanation are about using the new subcommand addif of ifconfig. It was not clear in the documentation if the setting logical interfaces via addif will persist across boot.
Can one still configure logical interface in Solaris 10 in a more traditional way like in Solaris 8? In an Solaris 8 server I will do the following.
Let's assume I want to configure in a solaris 8 server a logical interface named hme0:1 with IP address 192.168.20.28 with netmask 255.255.255.0 for hostname host001
# cat /etc/hostname.hme0:1
host001
^D
# echo "192.168.20.28 host001" >> /etc/inet/hosts
# echo "192.168.20.0 255.255.255.0" >> /etc/inet/netmasks
# reboot -- -r
Can one still do that in solaris 10 3/05 server?

Hi there,
I need to configure logical interface in a solaris 10
3/05 server. After reading the Solaris 10 IP services
manual, I am not quite sure what to do. All the
examples and explanation are about using the new
subcommand addif of ifconfig. It was not clear in the
documentation if the setting logical interfaces via
addif will persist across boot.No. No 'ifconfig' command is persistent.
Can one still configure logical interface in Solaris
10 in a more traditional way like in Solaris 8? In an
Solaris 8 server I will do the following.
Let's assume I want to configure in a solaris 8
server a logical interface named hme0:1 with IP
address 192.168.20.28 with netmask 255.255.255.0 for
hostname host001
# cat /etc/hostname.hme0:1
host001
^D
# echo "192.168.20.28 host001" >> /etc/inet/hosts
# echo "192.168.20.0 255.255.255.0" >>
/etc/inet/netmasks
# reboot -- -r
Can one still do that in solaris 10 3/05 server?Absolutely.
You don't need to reboot (you can run ifconfig for this boot and let the files do the work next time) and the -r doesn't do anything with interfaces (expecially virtual interfaces) anyway.
Darren

Installation problem on Solaris

I am trying to install sun one 7.0 on Solaris 8. The install is failing with this error:
ERROR - library load failed with following error: Can't load library: /opt/SUNWappserver7/lib/libinstallCore.so
INFO - End core server uninstallation
anyone know what causes this??
cheers

Looks like Solaris package installation failed and installer reverted to uninstallation sequence. For low level pkgadd log please check /var/sadm/install/logs/Sun_ONE_Application_Server_install.B<timestamp> file (timestamp is date and time of your installation attempt in mmddHHMM format).
Look for any errors in this file. Most likely thing that could have happened is that the installation of Java Help (SUNWjhrt) package failed because you didn't have existing package based J2SE installation on the system. If that's the case, workaround is to either preinstall package based J2SE installation or to selected option to install bundled J2SE that comes with application server.

Installation problem on Solaris 10

Dear All,
We are trying to install j2sdk 1.4.2_13 on solaris server zone. I have downloaded j2sdk-1_4_2_13-nb-5_0-solsparc-ml.bin
But when I try to execute this:
#./j2sdk-1_4_2_13-nb-5_0-solsparc-ml.bin
It gives me error: The installer is unable to run in graphical mode. Try running the installer with the -console or -silent flag
Tried with -console:
The wizard cannot continue because of the following error: Invalid command line option: console is not supported (10
01) (403)
WARNING: could not delete temporary file /tmp/ismp001/2599368
WARNING: could not delete temporary file /tmp/ismp001/6183226
WARNING: could not delete temporary file /tmp/ismp001/1222839
Then tried with -silent:
This time command just completed w/o any output at all.
Please suggest what can I do?
regards, Sean.

Dear Siddhesh,
Thanks for your reply.
I tried using X Manager GUI for my Solaris. But when I double click the j2sdk-1_4_2_13-nb-5_0-solsparc-ml.bin file to run it, it simply denies saying:
The filename "j2sdk-1_4_2_13-nb-5_0-solsparc-ml.bin" indicates that this file is of type "Unknown type". The contents of the file indicate that the file is of type "Shell script". If you open this file, the file might present a security risk to your system.
Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "Shell script", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file.
Also /tmp has full authorizations:
drwxrwxrwt 7 root sys 557 Jun 24 08:34 tmp
I dont have Hummingbird for X11 forwarding with this client. Do I have any other option??
regards, Sean.

STLPort 5.0.2 on Solaris 8

Similar Messages

Maybe you are looking for