0

I am experiencing some problems linking on Solaris 11.3 using Developer Studio 12.5.

The code appears to compile fine, but fails at the link stage:

CC  -o bin/libBlah.so -mt -G -z defs -fast -s -KPIC -xarch=generic \
-M mapfiles/solaris.map -library=stlport4 -staticlib=stlport4  \
<my .o files> <some boost .a libs> <openssl .a libs> \
-lCrun -lsocket -lnsl -lposix4 -lc -lm -lw -ldl

Undefined                       first referenced
symbol                             in file
void __Crun::ex_end_init()        obj/Blah.o
void __Crun::ex_start_init()      obj/Blah.o
ld: fatal: symbol referencing errors
gmake: *** [bin/libBlah.so] Error 2

If I remove the '-z defs' from the command line (link options), it will link fine. Running 'ldd libBlah.so' does not show any missing references.

A colleague used 'nm' to locate the symbols, which were only found in the static libCrun libs (not the shared libs):

# nm /opt/developerstudio12.5/lib/compilers/libCrun.so | grep ex_end_init
# nm /opt/developerstudio12.5/lib/compilers/libCrun.a | grep ex_end_init
00000340 T __1cG__CrunLex_end_init6F_v_

The manual advises using '-zdefs' to point out missing symbols, which we had done previously (makefile already had that flag), so, I am at a loss to explain what I am seeing.

Question is simply: What should I make of this and what should I do about it?

Jon
  • 1,675
  • 26
  • 57
  • What is the full set of compiler options used to generate your object files, including all those in your static libraries? – Andrew Henle Oct 05 '16 at 15:38
  • I captured this from a build: `...generating dependency for Base64.cpp ...compiling Base64.cpp CC -G -library=stlport4 -fast -KPIC -xarch=generic +w -library=stlport4 -DUNIX -DSOLARIS -DOS_UNIX -DOS_SOLARIS -D_RWSTD_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE -DLITTLE_ENDIAN -DUSE_PTHREADS -DNDEBUG -D_USESSL -D_USESSL -c Base64.cpp -o obj/Base64.o` – Jon Oct 05 '16 at 20:30
  • There are a few duplications since, some flags are set in globally defined and included makefiles, while others are defined in local makefiles (which include those globals). That's being cleaned up as we speak. – Jon Oct 05 '16 at 20:33
  • Is there really a `-G` in the `CC` commands used to generate things such as `obj/Base64.o`? That would make `obj/Base64.o` a shared object. See https://docs.oracle.com/cd/E37069_01/html/E37075/bkamw.html#OSSCPbkasa – Andrew Henle Oct 06 '16 at 15:43
  • We just avoid using stlport4 in Solaris Studio compilers for a different reason: with stlport4 std::string uses a global mutex for allocations, so in a multithreaded application that's the first bottleneck we encountered. No stlport4 since then, no regrets. – vond Feb 16 '17 at 17:46

0 Answers0