This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: libc-base patch status
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Jack Howarth <howarth at bromo dot med dot uc dot edu>, libc-alpha at sources dot redhat dot com
- Date: Sat, 14 Jun 2003 13:34:05 -0700
- Subject: Re: libc-base patch status
- References: <200306141811.OAA19815@bromo.msbb.uc.edu><3EEB747E.3030102@redhat.com>
On Sat, Jun 14, 2003 at 12:16:14PM -0700, Ulrich Drepper wrote:
> Jack Howarth wrote:
> > Has the libc-base patch HJ Lu proposed been rejected? This is
> > the patch posted in...
>
> I've never seen an adequate description of the problem and the way it is
> thought it should be. The test case is wrong since this basemodnew.c
> file defines symbols with empty version names but the version map
> doesn't export them. Empty version names are obviously not possible.
> If there are only problems with such invalid input this is a user
> problem and needs no changes in glibc.
>
Unspecified base version is documented in ld info pages:
---
To do this, you must use multiple `.symver' directives in the source
file. Here is an example:
__asm__(".symver original_foo,foo@");
__asm__(".symver old_foo,foo@VERS_1.1");
__asm__(".symver old_foo1,foo@VERS_1.2");
__asm__(".symver new_foo,foo@@VERS_2.0");
In this example, `foo@' represents the symbol `foo' bound to the
unspecified base version of the symbol. The source file that contains
this example would define 4 C functions: `original_foo', `old_foo',
`old_foo1', and `new_foo'.
---
It can be used to convert an existing unversioned DSO into a versioned
DSO without using a version name. The new version is only used when
the existing funtion's ABI is changed.
H.J.