This content has been marked as final. Show 6 replies
From the small amount of information you provided, it sounds like you have not compiled and linked all the needed definitions. The linker error message lists the functions that are missing. Be sure you compile all the associated source code and include the .o files in the link step.
To say more, I would need to see the actual test case, with the source code and the actual command lines you are using.
Did you also build libcppunit with Sun CC? (I don't know SuSE too well, but I suspect that libcppunit could be a pre-installed package)
I don't think that you can mix apps/libraries built with g++ and CC.
Paul is correct. You cannot mix g++ binaries with Sun C++ binaries. All the binaries must be produced by g++ or all by Sun C++.
yes I did compile cppunit with sunpro, because I already got that experience that libs can not be mixed between gcc and sunpro. Unfortunately I forgot that I also had an installed version from distribution DVD. But I linked with full path to the build version ,so I guess this is not the reason.
But now I removed the installed version and will retry next week with that (had not much time this week).
Ok, finally I got that working. The reason for unresolveds was a wrong sequence in link statement:
working: $(CC) $(ARC_FLAGS) $(OBJECTS) $(CPPUNITLIB) $(LIBS)
not working: $(CC) $(ARC_FLAGS) $(CPPUNITLIB) $(OBJECTS) $(LIBS)
for some reasons in solaris/sparc world this was no matter.
But there is another problem with syntax in $(CPPUNITLIB), to me these two statements should do same:
CPPUNITLIB = $(CPPUNIT_HOME)/lib/libcppunit.a
CPPUNITLIB = -L$(CPPUNIT_HOME)/lib -Bstatic -lcppunit
If I'm using the last one, I get the "dwarf error" and also lots of warnings like this appear:
/usr/bin/ld: Warning: size of symbol `std::string &std::string::operator=(constchar*)' changed from 482 in /opt/sunstudiomars/prod/lib/libCstd.a(instance.o) to 475 in /opt/sunstudiomars/prod/lib/libCstd.a(instance.o).
The first syntax does link without any errors or warnings. But the created binaray finally is doing its job (in both cases :-) .
The -Bstatic option is an order-sensitive directive. It means everything that follows on the command line will be linked statically.
-Bstatic should always be paired with -Bdyamic to avoid unintended consequences. Your second example should look like this:
CPPUNITLIB = -L$(CPPUNIT_HOME)/lib -Bstatic -lcppunit -Bdynamic
Even then, the two versions of the macro are not equivalent.
Puttting /path/to/mylib.a on the command line causes that specific library to be linked, and nothting else.
Putting -L/path/to causes the directory /path/to to be searched for every library that is not specified with its own path. If the directory contains somelib.a or somelib.so that is listed on the command line, you might get the wrong library.