Building TBB for Solaris/SPARC with Sun Studio C++ compiler

Building TBB for Solaris/SPARC with Sun Studio C++ compiler

Does anyone have experience building TBB for Solaris/SPARC with Sun Studio C++ compiler (CC)?

I am NOT sure whether TBB support Solaris/SPARC, but I am still trying to do so. Here is my environment:

chenwj@niagara:~$ uname -a
SunOS niagara 5.10 Generic_127127-11 sun4v sparc SUNW,SPARC-Enterprise-T5120
chenwj@niagara:~$ ls -la /usr/bin/CC
lrwxrwxrwx 1 root root 25 Mar 26 14:54 /usr/bin/CC -> /opt/sunstudio12.1/bin/CC
chenwj@niagara:~$ gcc --version
sparc-sun-solaris2.10-gcc (GCC) 4.3.3 (20091210) (gccfss)

I am going to build20100310 release (tbb30_20100310oss_src.tgz).

chenwj@niagara:~/work/svn/SPEC2006/tbb/trunk$ gmake compiler=suncc

Extended asm statements not supported

I guess I have to turn on optimization so that CC can recognize those assembly statements. I modify build/SunOS.suncc.inc. The difference is below:

# TODO: verify whether -m64 implies V9 on relevant Sun Studio versions
# (those that handle gcc assembler syntax)
ifeq (sparc,$(arch))
- CPLUS_FLAGS += -m64
+ CPLUS_FLAGS += -m64 -xO2
LIB_LINK_FLAGS += -m64
endif

After that, everything seems fine.

chenwj@niagara:~/work/svn/SPEC2006/tbb/trunk$ ls -la build/ | grep SunOS_sparc
drwxr-xr-x 2 nobody nobody 2952 Apr 2 20:21 SunOS_sparc_suncc_cc4.3.3_kernel5.10_debug
drwxr-xr-x 2 nobody nobody 2912 Apr 2 20:21 SunOS_sparc_suncc_cc4.3.3_kernel5.10_release

But when I build my program, it comes out some error messages at the linkage stage:

CC -m64 -xopenmp -xO3 -g -L /home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release -o mcf psimplex.o pstart.o readmin.o treeup.o implicit.o mcf.o mcfutil.o output.o pbeampp.o pbla.o pflowup.o -ltbb -ltbbmalloc

Undefined symbol first referencedin file

std::invalid_argument::invalid_argument(const std::string &) path/to/tbb/libtbb.so

std::range_error::range_error(const std::string &) path/to/tbb/libtbb.so

std::allocator::~allocator() path/to/tbb/libtbb.so

void std::__node_alloc::_M_deallocate(void*,unsigned long) path/to/tbb/libtbb.so

Any suggestion will be appreciate.

13 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi azru0512,

Could you check if unit tests work there? Is there the same errors?

gmake compiler=suncc test

--Vladimir

Thanks for your reply. The unit tests do not report the same errors.

However, it do report two errors.

gmake[1]: *** [malloc_test] Bus Error

gmake[1]: *** [test_tbb_plain] Bus Error

And there are some warnings, I don't know if they matters or not.

./test_pipeline_with_tbf.exe 1:4
Warning: out of order serial filter received tokens in order
done
./test_task_group.exe 1:4
Warning: No parallel waiting detected in TestParallelWait
Warning: No parallel waiting detected in TestParallelWait
Warning: No parallel waiting detected in TestParallelWait
Warning: No parallel waiting detected in TestParallelWait
done

Besides, the compiler=suncc option sometimes invoke cc (Sun Studio C compiler) not CC (Sun Studio C++ compiler) to do the compilation.

Regards.

p.s.Just to make sure that my program can run correctly on Solaris/SPARC. Does TBB support SPARC now?

I have a question about the runtime used to build TBB library.

I read the SunOS.inc in $(tbb_root)/build/ and noticed that if runtime variable is undefined, gcc's runtime is used by default.

In my case, it detected this.

chenwj@niagara:~/work/svn/SPEC2006/tbb/trunk$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /net/clpt-v490-1/export/data/bldmstr/20091210_ceres_gcc433/src/configure --prefix= --enable-shared --disable-static --with-system-zlib --enable-checking=release --enable-languages=c,c++ --with-cpu=v9 --with-ld=/usr/ccs/bin/ld --without-gnu-ld --disable-gnattools --enable-tls --with-as=/usr/ccs/bin/as --without-gnu-as
Thread model: posix
gcc version 4.3.3 (20091210) (gccfss) (GCC)

And the name of the directory contains TBB library confirmed that TBB library was built with runtime provided by gcc (gccfss).

SunOS_sparc_suncc_cc4.3.3_kernel5.10_debug

Since the errors in my original post occurred at linkage stage, MaximKartashevsuspected it maybe a problem to use gcc's runtime. See the link below.

http://forums.sun.com/thread.jspa?threadID=5434190&tstart=0

So what's the runtime library used to build TBB? Maybe I can use CC's runtime instead.

Regards.

Don't rely on the information in the folder name and the variable 'runtime' whichis only used to create the folder name. It does not actually reflect what C runtime is used; the only purpose it serves is to separate/distinguish builds made within different environments. In fact on Sun OS it's value is an artifact of porting from Linux. Sorry for this confusion; we probably need to make something better - proposals welcome.

To understand real dependencies on other shared libraries, use ldd. You may also look at the build log and see what libraries were specified in command line.

And by the way, if you identify any improvements/fixesto be done in TBB to resolve the issue you see, we would be glad to incorporate it; so please consider contributing necessary patches :)

Sure. But I have to solve some problems first. :)

Now the linkage errors were gone. However, when I link TBB library with my program,segmentation fault just happen, even don't use anything related to TBB in my program.

Any suggestion?

Regards.

Which of the TBB shared libraries do you link in? If multiple - can you determinea single library that crashes? Do you have a stack trace for the segfault?

Actually I link tbb and tbbmalloc in my program and each of them will causesegfault.

I use a simple program for example.

chenwj@niagara:~/tmp$ cat tbb.cc
int main()
{}

I compile it with libtbb.so.

chenwj@niagara:~/tmp$ CC -m64 -g -o tbb -R/home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release/ -L/home/chenwj/work/svn/SPEC2006/tbb/trunk/build/SunOS_sparc_suncc_cc4.3.3_kernel5.10_release/ tbb.cc -ltbb

And use dbx (Sun Studio debugging tool) to give me the stack trace. Here is the output.

chenwj@niagara:~/tmp$ dbx ./tbb
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc
Reading tbb
Reading ld.so.1
Reading libtbb.so
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libc.so.1
Reading libdl.so.1
Reading libpthread.so.1
Reading librt.so.1
Reading libstlport.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: tbb
(process id 17258)
t@1 (l@1) signal SEGV (no mapping at the fault address) in _private_memcpy at 0xffffffff7eb3a4d0
0xffffffff7eb3a4d0: _private_memcpy+0x0170: ld [%o1 + %g5], %o4
(dbx) where 1 -q -l
current thread: t@1
=>[1] libc.so.1:_private_memcpy()

Regards.

Hmmm, the stack is not very useful.

What if you remove (or rename) libtbbmalloc.so and only use (link with)libtbb.so? The latter uses the former under the hood, but if not found at runtime, it will switch to the libc malloc. I wonder if this will get you anywhere.

Well, the output of dbx is still the same. :(

chenwj@niagara:~/tmp$ dbx tbb
Reading tbb
Reading ld.so.1
Reading libtbb.so
Reading libCstd.so.1
Reading libCrun.so.1
Reading libm.so.2
Reading libc.so.1
Reading libdl.so.1
Reading libpthread.so.1
Reading librt.so.1
Reading libstlport.so.1
Reading libaio.so.1
Reading libmd.so.1
(dbx) run
Running: tbb
(process id 17353)
t@1 (l@1) signal SEGV (no mapping at the fault address) in _private_memcpy at 0xffffffff7eb3a4d0
0xffffffff7eb3a4d0: _private_memcpy+0x0170: ld [%o1 + %g5], %o4
(dbx) where 1 -q -l
current thread: t@1
=>[1] libc.so.1:_private_memcpy()
(dbx)

I wonder if there is a bug in libc.so?

Regards.

I found the answer onSun Studio C++ forum. See the link below.

http://forums.sun.com/thread.jspa?threadID=5435096

MaximKartashev kindly remine me that I should use "-library=stlport4" option everywhere or nowhere. Since the TBB library was built with "-library=stlport4" option, I should use this option when I build my program.

The point is that there is a default STL implementation on the system, and there is another one come with Sun Studio. If I don't use"-library=stlport4" option everywhere, then there are two STL implementations exist simultaneously which cause the program crash.

Thanks for the information.
Do you have any changes in TBB that you could contribute to us, for improved support of Sun OS?

Leave a Comment

Please sign in to add a comment. Not a member? Join today