This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: The remaining dubious symbols in libgcc-std.ver
- To: "Zack Weinberg" <zackw at Stanford dot EDU>
- Subject: Re: The remaining dubious symbols in libgcc-std.ver
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 14 Jun 2001 00:30:40 -0300
- Cc: Mark Mitchell <mark at codesourcery dot com>, Mark Kettenis <kettenis at science dot uva dot nl>, "rth at redhat dot com" <rth at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Organization: GCC Team, Red Hat
- References: <20010612190104.B302@stanford.edu>
On Jun 12, 2001, "Zack Weinberg" <zackw@Stanford.EDU> wrote:
> I'm not sure what -Wl,-set_version,gcc.0 means as an alpha/osf4 link
> option or whether it's appropriate to bump the 0 to 1 (I did bump it
> in this patch). That one doesn't seem to use map files.
It seems appropriate, as far as bumping the version number for the
first release is appropriate. I don't think it is. There only point
of bumping the version number of a shared library is to mark is as
binary-incompatible with any other release of that shared library.
Since there are no previous releases, I think doing this for GCC 3.0
is pointless. Since there is a risk involved of doing it at this time
in the release cycle, I'd rather not do it.
Besides, we shouldn't be making it an habit to mindlessly bump shared
library version numbers before releases. One of the most important
issues about shared libraries is that you want to *avoid* bumping its
major version number, so that programs compiled with earlier releases
of the compiler keep working without needing a backward-compatibility
shared library. I believe this is the kind of thing H.J. Lu and Uli
Drepper refer to when they say we have no idea of how to manage shared
libraries.
As for -set_version on OSF and IRIX, it expects a list of versions the
library being built is compatible with. Think of minor version number
for the ELF equivalent. Since there are no earlier versions to be
compatible with, gcc.0 (or gcc.1) is appropriate.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me