Compatibility between solaris versions?
Henrik Goldman
right direction.
I have some users who'd like to use a static library that I'm creating. They
want to link it into their binary and use it as a part of their app.
This library compiles fine with g++ on Sol 10 and links succesfully with gcc
as frontend-linker. However my users would like to use it on elder versions
of solaris. e.g. sol 8. So I found out that Solaris 8 does not come with gcc
like 10 does. The question is if I can assume things to work if I would
compile my C library under 10 and make users link it with SunCC under 8?
From what I've read so far the object format should be the same between gcc
and Sun Workshop.
Perhaps it would be a better way to go for the lowest possible version? In
that case could I assume the library would work on Solaris 10 if it was
compiled on 8?
I don't expect the library to compile flawlessly with SunCC so naturally I'd
like to stay with gcc if possible. However Solaris 8 doesn't offer gcc from
it's installation. I would have to get the binary package from one of the
websites on the net. It's not like it's a problem but I wonder about binary
compatibility.
The library itself is a networking library. It is written in C++ and
compiled with g++ but the C++ dependencies has been hidden by re-linking the
object code of libstdc++ into my lib.
Are there any issues with glibc that I should be aware of between the
Solaris versions?
Thanks in advance.
-- Henrik
Paul Pluzhnikov
> I have some users who'd like to use a static library that I'm creating. They
> want to link it into their binary and use it as a part of their app.
> This library compiles fine with g++ on Sol 10 and links succesfully with gcc
> as frontend-linker.
C++ code is a big problem. See below.
> 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.
> So I found out that Solaris 8 does not come with gcc
> like 10 does.
This is entirely irrelevant. Even on Solaris 10, your users could
be using different version(s) of gcc, regardless of what is or
isn't installed by default.
> The question is if I can assume things to work if I would
> compile my C library under 10 and make users link it with SunCC under 8?
You can't assume anything, but the probability that it will work
is quite high.
> From what I've read so far the object format should be the same between gcc
> and Sun Workshop.
Correct.
> Perhaps it would be a better way to go for the lowest possible version? In
> that case could I assume the library would work on Solaris 10 if it was
> compiled on 8?
Yes (except for the C++ issues, see below).
> The library itself is a networking library. It is written in C++ and
> compiled with g++ but the C++ dependencies has been hidden by re-linking the
> object code of libstdc++ into my lib.
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}
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.
> 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*.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Ian Collins
> I am a bit new with solaris but hopefully someone here can guide me in the
> right direction.
>
> I have some users who'd like to use a static library that I'm creating. They
> want to link it into their binary and use it as a part of their app.
> This library compiles fine with g++ on Sol 10 and links succesfully with gcc
> as frontend-linker. However my users would like to use it on elder versions
> of solaris. e.g. sol 8. So I found out that Solaris 8 does not come with gcc
> like 10 does. The question is if I can assume things to work if I would
> compile my C library under 10 and make users link it with SunCC under 8?
>
> From what I've read so far the object format should be the same between gcc
> and Sun Workshop.
>
Yes for C.
> Perhaps it would be a better way to go for the lowest possible version? In
> that case could I assume the library would work on Solaris 10 if it was
> compiled on 8?
Yes, that's standard practice on Solaris.
> I don't expect the library to compile flawlessly with SunCC so naturally I'd
> like to stay with gcc if possible. However Solaris 8 doesn't offer gcc from
> it's installation. I would have to get the binary package from one of the
> websites on the net. It's not like it's a problem but I wonder about binary
> compatibility.
>
You would have to use a gcc (such a Blastwave) built for Solaris 8 on
both platforms. Or simply build and package your application on Solaris 8.
> The library itself is a networking library. It is written in C++ and
> compiled with g++ but the C++ dependencies has been hidden by re-linking the
> object code of libstdc++ into my lib.
You could try to clean up the code so it compiles with Sun CC, unlike
gcc, Sun CC retains ABI compatibility across versions.
To link on with Sun CC, all C++ interfaces would have to be exern "C".
> Are there any issues with glibc that I should be aware of between the
> Solaris versions?
>
Not used.
--
Ian Collins.
Henrik Goldman
>> 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
>> gcc
>> and Sun Workshop.
>
> Correct.
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
Paul Pluzhnikov
> Do you perhaps know how well SunCC compares to gcc?
Portable code compiles with both pretty well, but there are
significant differences in what these compilers will accept as
valid ...
Ian Collins
>>>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.
>
is also more pedantic, I've found just about all code that compiles with
CC will compile with gcc, but the converse is definitely not true. A
significant number of open source packages are targeted at Linux and the
code is often riddled with gcc specific extensions. Variable length
arrays are one example.
>
> 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.
>
I cuts both ways, Sun CC maintains ABI compatibility and the expense of
standards compliance.
One tip - when porting from gcc, compile with -library=stlport4. The
standard CC STL has a number of omissions (to maintain ABI compatibility).
--
Ian Collins.
Paul Pluzhnikov
> It
> is also more pedantic, I've found just about all code that compiles with
> CC will compile with gcc, but the converse is definitely not true.
Your mileage is different from mine.
I have somewhat non-negligible number of C++ test cases which are
accepted by SunCC, but are illegal and are rejected by g++-3.4.
In fact, the most 'pendantic' compiler I know is HPs aCC -- it
requires no 'special handling' in the EDG C++ front end. Both SunCC
and g++ require exceptions (as in "this code is wrong, but accept
it in Sun mode or g++ mode"). In the EDG C++ FE v3.7:
$ grep sun_mode *.c | wc -l
60
$ grep gpp_mode *.c | wc -l
188
The above numbers reflect compatibilty back to g++-3.0 and Sun
Workshop6.2. If you only considered Studio11 and g++-4.x, the number
of exceptions would be smaller.
Both of the above are dwarfed by Microsoft though:
$ grep microsoft_mode *.c | wc -l
514
Ian Collins
> Ian Collins <ian-...@hotmail.com> writes:
>
>
>>It
>>is also more pedantic, I've found just about all code that compiles with
>>CC will compile with gcc, but the converse is definitely not true.
>
>
> Your mileage is different from mine.
>
> I have somewhat non-negligible number of C++ test cases which are
> accepted by SunCC, but are illegal and are rejected by g++-3.4.
>
both Solaris and Linux and I found it best to use Workshop 6.2 as a
baseline. The Sun compilers don't have as many non-standard extensions
as gcc.
> In fact, the most 'pendantic' compiler I know is HPs aCC -- it
> requires no 'special handling' in the EDG C++ front end. Both SunCC
> and g++ require exceptions (as in "this code is wrong, but accept
> it in Sun mode or g++ mode"). In the EDG C++ FE v3.7:
>
> $ grep sun_mode *.c | wc -l
> 60
> $ grep gpp_mode *.c | wc -l
> 188
>
> The above numbers reflect compatibilty back to g++-3.0 and Sun
> Workshop6.2. If you only considered Studio11 and g++-4.x, the number
> of exceptions would be smaller.
>
Indeed, both have improved their standards compliance, 6.2 is rather old
now.
> Both of the above are dwarfed by Microsoft though:
> $ grep microsoft_mode *.c | wc -l
> 514
>
:)
--
Ian Collins.
Henrik Goldman
There were a few problem with compilation since some header files were not
available in this old version (e.g. stdint.h).
Having downloaded gcc-3.3.2
http://www.sunfreeware.com/programlistsparc8.html#gcc33
it seems there are a few weird things going on:
ld -r temp/SunOS_sparc/to_be_fixed.o temp/SunOS_sparc/cinclude.o -o
temp/SunOS_sparc/rtw.o
ld: warning: sparc:v9 architecture of input file
`temp/SunOS_sparc/to_be_fixed.o' is incompatible with sparc output
If both files are 64 bit why does it try to default to 32 bit output?
Maybe is there a switch to change it to 64 bit?
Also it seems that libstdc++.a is a 32 bit file but I hope I that 64 bit
version exist also. Otherwise I guess I'll have to try recompile gcc if
possible.
-- Henrik
grid
pass the -xarch=v9 compiler flag to generate 64 bit objects.
HTH