[gccsdk] Shared library status update

Lee leenoar at sky.com
Tue Jan 8 12:19:31 PST 2008

Peter Naulls wrote:
> John, Lee - can we have an update of the present state of shared 
> libraries?  Any known issues, or stuff to avoid, or things you'd like
>  tested.

AFAIK, there are no problems with general use of shared libraries, but
it's not been exhaustively tested. The biggest test the system has had
so far is GCC itself where you have potentially 3 clients on the go at 
the same time (make, gcc, {cc1,as,ld}). Although I've tested multiple 
taskwindows running with different clients, I haven't tried multiple 
WIMP tasks, but I see no reason why that should fail.

Things to avoid might include facilities that the latest dynamic loader
supports, but version 1.9.9 doesn't, e.g, cyclic dependencies and
libraries as filters. I think the dynamic loader has to include support
for these features which v1.9.9 definitely does not.

I believe the __som_got__ symbol is causing some problems because it is
automatically being hidden by version scripts when it should be
exported. This is because is starts with an underscore, which I used to
emphasize the fact that it's a system symbol. I could rename it to
som___got, which unfortunately brings it into the user namespace, but I
think the use of 3 underscores in the middle should ensure that it
doesn't clash with any user symbols.

> Perhaps we can also have some opinions on how shared libraries ought 
> to be distributed - wrt to packaging and !DSO-Libs.

I originally intended to sub divide !DSO-Libs.lib to categorise the
libraries that were installed (hence the system directory), but I'm not
sure that's really necessary, so perhaps a flat structure should be used.
The easiest way to package would seem to be within a skeleton !DSO-Libs
including their runtime and compile time symlinks (rather than
generating them automatically during installation as Linux does). If we
could standardise the way library names include their version number,
then that could be used for version control and riscpkg would know
whether to overwrite an existing version or not. We don't have to
enforce this, but if a library doesn't include it's own version in the
filename, then it runs the risk of overwriting a newer version.


More information about the gcc mailing list