Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!odi!benson
From: benson@odi.com (Benson I. Margulies)
Newsgroups: comp.lang.c++
Subject: Re: SunOS shared libraries and virtual tables
Message-ID: <1991Mar20.121854.6308@odi.com>
Date: 20 Mar 91 12:18:54 GMT
References: <68989@brunix.UUCP> <1991Mar19.151044.4762@linus.mitre.org>
Organization: Object Design, Inc.
Lines: 30
In-Reply-To: dsr@mir.mitre.org's message of 19 Mar 91 15:10:44 GMT

Our experience is this:

Ignore sun's description of "exported, initialized data." It is, in
fact too narrow.

If its a global scope item with a non-zero initialization, put it in
the .sa archive, whether or not is is "exported." According to sun's
documentation, writable items accessed purely within a libary aren't
supposed to require placement in the .sa file, but something is wrong
(documentation or code, I don't know which) and they come up zero if
they aren't in the .sa file.

A tip-off of trouble is "creeping B disease." If you forget to move
something to exports, it will show up in the base executable as a "B",
as well as being a "D" in the library.

Vtbls are not modified at runtime by sane programs, and so can stay in
the shared libs. Our do, and are perfectly happy.

Watch Out For Static Constructors! munch has no way to distinguish the
constituent .o files of a shared lib, so static constructors for a
shared lib are an all or nothing proposition.

It is possible to use patch (actually, nothing at all) rather than
munch for SunOS shared libs, but you have to replace _main with a
version that crawls around the structures hanging off _DYNAMIC
at runtime. 

-- 
Benson I. Margulies