subject:"Re\: \[PATCH\] note the __sF change in src\/UPDATING"

Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING)

2002-11-12 Thread Terry Lambert

Loren James Rittle wrote:
 FYI, the libstdc++-v3 maintainers on the FSF side are only
 guaranteeing forward ABI compatibility of any sort if libstdc++.so is
 built with symbol versioning and symbol hiding.

FWIW: symbol versioning is incredibly broken.  It attempts to
do in UNIX what interface versioning does in Windows, through
the use of class factories accessed via IUnknown.  The point of
the exercise is to allow multiple simultaneous versions of an
interface to be exported by a single library.

The main reason this is bas is the same reason that Novell must,
in their SDK's, support interface versions all the way back to
NetWare 1.x: in order to hve the largest possible user base, a
software vendor would have to be stupid to write to anything
other than the lowest common denominator of interfaces: it's
really stupid to limit your customers to running NetWare 4.2 or
above, when there is still such a large installed base of 3.x,
4.0, and 4.1 versions of NetWare.  The only thing you do when
you do that is to disenfranchise postential customers for your
product.

Windows uses this approach because they do not have the concept
of shared object versioning; VCRTL32.DLL is VCRTL32.DLL, no
matter what, so a version change that permits old applications
to continue working is a the same DLL, plus extensions (since
there is no version in the file name,multiple versions can only
exist simultaneously if they exist in the same file).

It would be a very big mistake to actually utilize symbol name
versioning on a UNIX system, and buy into this model, even if
the idea was supported by the tools.  That Linux has bought into
the idea of using this is, frankly, Linux's problem, and they are
going to regret it in the future as much, or more, than they
regretted implementing shared library support in the SVR3.2 way,
of linking libraries to fixed locations, and carving up chunks
of the user virtual address space to implement them, back when
they first supported shared libraries.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING)

2002-11-12 Thread Terry Lambert

Loren James Rittle wrote:
FWIW: symbol versioning is incredibly broken. It attempts to
do in UNIX what interface versioning does in Windows, through
the use of class factories accessed via IUnknown.

You might be absolutely correct in general. However, please read
http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt . It is clear that
symbol versioning is not being used at all like you supposed it might
have been (mis-)used.

To provide multiple API's in a single shared library image, to
avoid a number of images being necessary?

That's exactly how it's being used; they call it age gracefully,
but what that means is that multiple API versions remain supported
for a very, very long time, without having seperate libraries
involved.

Technically, the symbol decoration used in C++ is also in error;
it's there simply to avoid having to change the object file format
to accomodate interface attributes seperately from the symbol name
(just as adding an @@version name suffix does). If this were
not ther, the linker could automatically create glue code for doing
argument coercion, and it would save a lot of code that currently
has to be supplied by programmers.

FWIW: There is no concept of IUnknown or
implementation factories (and, yes, I do understand those concepts) in
how libstdc++.so (v3) is using symbol versioning. I invite you to
take a close look at how that library is actually using symbol hiding
and versioning before you attempt to cast your judgment. If you have
informed comments, then please direction them to [EMAIL PROTECTED]
not me personally (as a libstdc++-v3 maintainer, I will read them over
there like all others).

I'm well aware of how it's used; the IUnknown reference was an
analogy; the document you refer to specifically states that it's
to avoid a proliferation of shared library files. That's exactly
the purpose of IUnknown version information for class factories,
as well.

Part of the problem here is that GCC dropped the minor version
number from shared libraries in binutils, and FreeBSD and Linux
followed suit. Now this turns out to be a mistake, and rather
than admitting the mistake, instead now we have more decoration
occurring in the symbol name to fake up another orthogonal namespace.

Traditional UNIX systems have minor versions on shared libraries
to address this, and bump major versions only if existing interfaces
change, not when interfaces are added (thus program foo linked
against lib.so.M.N works just fine against lib.so.M.N+K).

If you don't like the Microsoft DLL version analogy, a different
analogy is the Aztec C support for directories, by naming files
with their complete path, and treating the character / as a
path component seperator in order to achieve a namespace escape,
when the Mac FS didn't support directory hierarchies.

In all cases, what's happening is a namespace incursion in order to
permit coexistance of otherwise conflicting implementations.

Short summation: We only mark the first version of the library that a
new symbol is added. E.g. there will never be [EMAIL PROTECTED] and also [EMAIL PROTECTED]
The first release after an ELF library version number bump resets all
tags to be the same. As clearly documented, libstdc++.so (v3) will bump
the major version number just like FreeBSD does on installed shared
libraries to express other sorts of C++ compiler or library ABI change.

This still fails when the OS version does not bump each time the
compiler version bumps. I guess this is OK, if you are a compiler
vendor, but less OK, when you are an OS vendor. 8-).

If the system compiler of FreeBSD still wanted to install multiple
versions of libstdc++.so (v3) with major number bumps for other
reasons (because it is considered safer for compatibility by the
system designers), that would be quite fine. But completely ignoring
the symbol hiding features will make the FreeBSD C++ system compiler
and environment worse than the Linux version and worse than a g++
installed from equivalent FSF sources IMHO (since we will leak all
sorts of internal implementation symbols that are not suppose to
influence user application link behavior). Anyways, Alex was already
going to look into trying this for the FreeBSD 5.0 system compiler so
hopefully this will not be the case.

No, it will make it incompatible, which is rather annoying, but
it's an introduced incompatability that came from the compiler,
and we shouldn't pretend it isn't.

In any case, the issue was in attempting to prevent the exposure
of data interfaces, and symbols not part of the defined API; this
is still goinf to cause problems for the reasons this discussion
came up in the first place: other language compilers that need to
link against system libraries, and share implementation instances
so that they can be linked against foreign object files that use the
same underlying implementation. For the purposes of this discussion,
that's the stdio implementation, as exposed

58 matches

Mail list logo