Curt Arnold wrote: > Is it unbearably hard to make the automake build to create a single It is ;-)
> test executable without using an intermediate library? Breaking the > test suite up into a small driver and a shared library of tests has got > to make debugging in some IDE's more complicated than just having a > single test executable. I have to examine this further. I did not find a solution so far (the issue are the global cppunit registration objects which register the test cases with the cppunit framework). The linker usually throws away the objects which contain those global variables, because there are no references from the main program into the objects. Maybe there is another solution... > While you are playing on Solaris, have you had a chance to try the Sun > compilers. Apparently, they are now available through opensolaris.org, > but the site is not responding well at the moment. I have just run the sources through the ForteV7 compiler. The library builds, but simplesocketserver fails to link due to unresolved symbols: unsigned log4cxx::helpers::UnicodeHelper::decodeWide(const wchar_t*&,const wchar_t*) int log4cxx::helpers::UnicodeHelper::encodeWide(unsigned,wchar_t*) int log4cxx::helpers::UnicodeHelper::lengthUTF8(wchar_t) log4cxx::pattern::FormattingInfo::FormattingInfo(const bool,const int,const int) void log4cxx::pattern::FormattingInfo::format(const int,std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)const The first three seem to result from neither _WIN32 (natural on Solaris) nor __STDC_ISO_10646__ being defined in unicodehelper.cpp. Need to have a look at it. The latter two are caused by different parameter type qualifiers (const/non-const) which does not seem to be a problem for gcc. Should be easy to fix. Regards, Andreas
