In the process of rebuilding very large and very old application I noticed that /usr/openwin/lib no longer seems to have any .a libraries. Needless to say I need to link against a few.
Any idea on why Solaris 10 no longer delivers these libraries or did I make an install mistake. I could take them from Solaris 8. Not even sure I really need them.
This might become a frequently asked question, so I wrote the answer on my blog. You can read about it here:
http://blogs.sun.com/roller/page/quenelle?entry=solaris_10_ack_where_did
That blog entry points to these two answers by other people:
http://blogs.sun.com/roller/page/rie?entry=static_linking_where_did_it
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4470917
Ok. Thank you very much. That probably explains some of the strange instability I have been seeing even though most of the application seems to be working fine.
So would it be safe to say that any application running under Solaris 10 that has linked in .a libraries runs the risk of being unstable? Or to put it another way, the official Sun guidance is that we should only use dynamically linked libraries under Solaris 10.
Aside from the blog entries and such have you seen any similiar statement posted on Sun's site somewhere? I need to bring this to the attention of my management.
Any "instability" really depends on which libraries you are talking about, and
it only results if the underlying implementation changes in a specific
way. So if you statically linked programs on Solaris 9, it is safe to say
they will run reliably (no instability) on Solaris 10. But you should
migrate to useing dynamic libraries, if at all possible. (At least when
using Solaris)
You have specific questions about possible instability with libX11.a, you
should try asking on the opensolaris forum for 'desktop' software. I think
that's the closest "community" to the X windows area.
It wasn't widely broadcast because we believe we did a very good job
of making the whole thing transparent for the majority of users.
(But it's a little out of my area so take that with a grain of salt)
--chris
Ok. Thanks again.
It's not really specifically about libX11.a but rather about .a libraries in general. We have .a libraries scattered about and linked in all over the place. Our code goes back to at least 1985 so if it could be done then we have done it.
The instability I am seeing basically manifests itself by having some static variables getting clobbered. The app is rock solid under Solaris 8.
Ah ha! I see that I wasn't clear about something.
There is no problem with linking *application* archive libraries on Solaris 10. We do
it all the time. The problem comes up depending on *which* libraries you
are talking about. The change in Solaris 10 was that Solaris was no longer
going to export Solaris functionality using archive libraries. That's an
interface decision that Sun made because it is easier for us to keep our
interfaces stable, and to keep old programs working on a newer OS.
So in general there is no problem with the basic functionality of static linkking.
I'll have to update my blog entry.
Right. But let's assume that I have linked in Solaris 8 versions of .a libraries. So I basically have Solaris 8 object code in my Solaris 10 app. Am I really gaurenteed that the Solaris 8 .a code will run? I don't have to worry about all the threadsafe stuff talked about in your third link from your original post?
Again, I am slowly rebuilding our app so I can use dbx to track down these memory issues. Or maybe they will just go away after a recompile. Just trying to come up with a sensible explanation on why something that worked well under Solaris 8 would almost but not quite work under Solaris 10.
Rebuilding with shared libraries is a good idea. If that makes your
bugs go away, then that's great.
The majority of code in all the archive libraries on Solaris 8 will
(I believe) run just fine on Solaris 10. So it could still be something
else that's making your program crash.
You can use dbx without recompiling your application, and the
"stop access" command will still work. The stack trace that you
see when the program stops will be harder to understand if the
program or libraries were compiled without -g.
Whether a system library from Solaris 8 will run on Solaris 10 depends on what assumptions those libraries make about low-level functionality. One reason for abandoning static system libraries was that it was becoming increasingly difficult to preserve those low-level details.
A good example is the underlying thread model on Solaris. The traditional model of non-threaded versus multithreaded programs meant maintaining at least two distinct program models in systems libraries and in the Solaris internals. Solaris 10 changed the model so that all programs are "multithreaded", although some programs use only one thread. The change drastically simplified Solaris, and eliminated some possible sources of bugs.
The public APIs are not affected -- you can write your programs the same way on Solaris 10 as you did on, for example, Solaris 8. Binaries you generated from your source code on Solaris 8 will still link on Solaris 10 and run the same way.
But Solaris 8 system libraries might depend on Solaris internals that are different in Solaris 10. System libraries are not constrained to use only the public APIs.
Since in general you cannot know whether a system library uses non-public Solaris interfaces, you should not depend on static libraries working on a different Solaris version.
