[lsb-discuss] Enabling FP traps in LSB code

Theodore Tso tytso at mit.edu
Fri Nov 16 10:02:54 PST 2007


On Fri, Nov 16, 2007 at 11:51:36AM +0100, Dallman, John wrote:
> > Hmmm ... now that's interesting. Do you really *mean* UNIX 
> > platforms or do you mean "platforms that have some similarities 
> > to UNIX". The Single UNIX Specification has very defined behavior 
> > for dlopen(), and it *cannot* vary from that and still be called 
> > UNIX (OK, it can have extensions, but the base line required by 
> > SUS cannot differ). 
> 
> They were badly bitten by inconsistencies in the days before 
> those standards existed, and have remained sceptical. And 
> sadly, the number of companies that would regard Single UNIX
> Specification conformance as an important element of their 
> choice of platforms is rather small. As a commercial 
> organisation, we have to support what the customer wants,
> most of the time. 

Looking at SUSv3, there are still one or two ambiguities that I could
see, that come from the fact that shared library linking is not
exactly tightly defined.

For example, suppose Shared library 'A' uses pulls in berkdb 4.2, and
Shared library 'B' uses and pulls in berkdb 4.3.  If an application
tries to link in Shared libraries 'A', 'B', and berkdb 4.4, the result
is very much undefined, and on some systems, can lead to segfaults.
As far as I know no specification today specifies whether or not such
an arragement (where berkdb 4.2, 4.3, and 4.4 are shared libraries
that export mutually incompatible functions with identical symbol
names) is allowed and what the behavior would be in such a situation.

The dlopen() call does define RTLD_GLOBAL and RTLD_LOCAL, which
attempts to address a related problem, but as specified, the SUSv3
only places constraints on what the implementation does with respect
to visibility of the symbols in the object file directly loaded by
dlopen().  It is silent about what happens to shared libraries which
are dragged in as a result of the dlopen().  One could easily infer
that if an object file is loaded using dlopen() with RTLD_LOCAL, all
libaries which are dragged in via dependencies should also have local
symbols --- and that just because db_open has already been defined by
a shared library, berkdb4.2, if the shared library explicitly
specifies a dependency on berkdb4.3, berkdb4.3 should be loaded ---
but this is not guaranteed by the spec, and I daresay many
implementation might even fail to do this.

Another question which comes up is if two instances of the same shared
library are loaded, with or without RTLD_LOCAL, and either with or
without being explicitly linked in, explicitly loaded via dlopen(), or
implicitly loaded via dependencies, do you get two instances of the
shared library as far as static variables inside said shared
libraries, or not?

Indeed, are static variables inside shared libraries supported?
Historically, some implementations did not support static variables
inside shared libraries; some did not support the ability for shared
library code to be able to access global variables provided by the
calling application.

						- Ted



More information about the lsb-discuss mailing list