Re: Compatibility between solaris versions?

However my users would like to use it on elder versions
of solaris. e.g. sol 8.

That should (in theory) work fine; but is not guaranteed to work.
In general, you should develop on the oldest release you plan
to support.

Yes you're right. Do you perhaps know how well SunCC compares to gcc? On an
average basis is there lots of conflicts between those two? I know it's a
vague question but I would rather not invest too much time into old software
from the last century without a good reason.

From what I've read so far the object format should be the same between
and Sun Workshop.


So far so good. Then there should be a little bit of hope left.

Relinking libstc++.a into your library is necessary, but not sufficient.

You must also hide all C++ symbols inside your library (man objcopy,
see --localize-symbol). If you don't, and the end-user does this:

g++ main.o -lYourLib

there is a high chance he'll get symbols, defined in libstdc++.a (such as
'std::basic_string<...>::basic_string()') from your library,
instead of from his own libstdc++.{a,so}

Yes I already do that. I use objcopy -G but I forgot to write. I've also
verified with nm that they are local (except public symbols).

Unfortunately, g++ 3.0, 3.1, 3.2 and 3.3 all have (slightly)
different ABI, and the result of (e.g.) g++ 3.1 compiled user
code calling your g++ 3.4 (or whatever version you actually used)
compiled libstdc++.a will likely be a crash.

I actually wonder why anyone invented the word "compatibility". It seems
like wasted amount of characters put together. Compatibility is one thing
that gcc does not have for sure. It's a little bit annoying since you never
know if things work or not.

Are there any issues with glibc that I should be aware of between the
Solaris versions?

Solaris doesn't use glibc. You don't need to worry about *that*.

Heh... One problem less then. ;-)

-- Henrik