Re: [Patch, libgfortran] PR 27740 Versioned symbols, bump so version

[Janne Blomqvist <jblomqvi at cc dot hut dot fi>]

On Tue, May 23, 2006 at 09:10:54PM +0100, Paul Brook wrote:
> > Now, the point with ABI compatibility, and how to use versioning to
> > achieve it in a somewhat robust way, is that instead of modifying the
> > interface of function foo and hence be forced to bump the so version,
> > one can create a new function foo2, put it into a new version and
> > still keep the original function foo.
> 
> Actually you're more likely to rename foo to foo_old and create a new foo.
> 
> > Also the frontend needs to be 
> > modified to generate code to call foo2 instead of foo. Well there are
> > ways to avoid adding new names, but these seem to require __asm__
> > directives, and it seems none of the gcc libraries use it.
> 
> No. The whole point of symbol versioning is that the compiler (or user) still 
> reference "foo". You can change the interface of foo without needing to 
> change its name.
> 
> To maintain backwards compatibility with old binaries you create a new version 
> of foo in the library. Apps linked against the new library (using the new 
> compiler) will refer to the new foo version2. Old binaries will still refer 
> to foo version1 (which may be implemented internally as foo_old).
> 
> The point is that each dynamic symbol is identified by both its name and its 
> version. At static link time symbols are bound to the default version of the 
> named symbol.

Fair enough. But AFAICS having multiple versions of the same symbol
requires the __asm__ trickery, no?

But even without this capability, a nice feature of symbol versioning
is (from
http://www.tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html):

"Typically references to external functions are bound on an as-needed
basis, and are not all bound when the application starts up. If a
shared library is out of date, a required interface may be missing;
when the application tries to use that interface, it may suddenly and
unexpectedly fail.

A solution to this problem are symbol versioning coupled with version
scripts. With symbol versioning, the user can get a warning when they
start their program if the libraries being used with the application
are too old."

> Also, if we're changing the ABI of libgfortran we may as well get it right. 
> Your map file shows several exported functions that are not prefixed with 
> _gfortran.

Yes. Seems many of these functions are implemented in F90, so that's
why they were left out of this export_proto business. Shouldn't be too
hard to fix.

What about the f2c entry points? Should they also be renamed
_gfortran_f2c_*, or is the current f2c_* good?

For the remaining cases, find_or_create_unit seems like a genuine
oversight, _init and _fini are related to the library contructor and
destructors. Which leaves abort_ and etime_. I have a vague memory
that these were available for some reason, perhaps related to the
testsuite? In any case, they are also available as _gfortran_abort and
_gfortran_etime.

-- 
Janne Blomqvist

Attachment: pgp00000.pgp
Description: PGP signature