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

[Paul Brook <paul at codesourcery dot com>]

On Tuesday 23 May 2006 22:16, Janne Blomqvist wrote:
> 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?

No. You use the version script to map the different versions onto the 
appropriate internal symbols.

> > 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?

I don't remember what these are for. I'd guess _gfortran_f2c_