On Sat, 25 Aug 2007, Stefan Teleman wrote: >> What about other programs that are linked against either library? Will they >> play well together? > > Unfortunately, no. The two libraries are mutually exclusive. Linking a > program against both libraries will result in undefined behavior, and the > program will most likely not work, behave strangely, or crash. Also, linking > a program against libraries which in turn link against both Sun libCstd.so > and the Apache/RogueWave Standard C++ library also will not work.
This seems like we're between a rock and a hard spot on that one. >> Does this mean that the entire stack which runs together, must be compiled >> with the same? IOW, if someone wanted to write a kde app, would they be >> required to use the same Apache/RogueWave Standard C++ Library? > > Yes, unfortunately this is a very restrictive requirement. The class > instances defined in these libraries will have different sizes, and they are > incompatible. The symbol conflict is similar to linking a program against > two different and incompatible versions of the Standard C Library. That creates a mess, IMO. >> This might be a dumb question, but what about getting the compiler folks to >> change Studio 12 to be 100% compliant with the ANSI/ISO C++ Standard? >> >> This would allow us to use the libCstd.so from Sun, right? > > I did ask -- the problem is that making libCstd.so 100% Standard compliant > will break binary compatibility. Studio 12 itself is very close to being 100% > Standard compliant. libCstd.so is not, because it must stay compatible with > older versions of Workshop/Forte/Studio, going back to Workshop 5. I would fear we put ourselves into a similar situation as having incompatible ABIs between SunStudio and gcc. I'm not sure that's a good situation for us to be in. Not that I have a solution to the problem, but it doesn't seem to solve the heart of the problem at hand, rather create one of it's own. -- Alan DuBoff - Solaris x86 IHV/OEM Group
